CVE-2026-101187: Ziroom ZHOME A0101 Flaw

What Happened, in Brief

CVE-2026-101187 affects the Ziroom ZHOME A0101 device, specifically firmware version 1.0.1.0. The vulnerable code is the pop_usb_device function in usr/lib/lua/luci/controller/api/zrUsb.lua, part of the device’s USB Device Management API. Manipulation of the path argument can result in operating-system command injection.

The NVD record describes the issue as remotely exploitable and assigns a critical base score of 9.1. The available record does not identify an official vendor patch, a fixed firmware version, or whether the affected API requires authentication.

The lack of a confirmed patch is a remediation gap, not evidence that later firmware is safe. Verify the exact firmware build on every device, and do not assume that an undocumented upgrade resolves the flaw.

What’s the Root Cause?

The root cause is inadequate handling of the path argument passed to pop_usb_device. The available vulnerability description states that manipulating this argument causes command injection. In practical terms, attacker-controlled input appears to reach a command-execution path without sufficient validation, escaping, or safe API handling.

The affected code path is identified as follows:

usr/lib/lua/luci/controller/api/zrUsb.lua
    └── pop_usb_device()
        └── path argument
            └── command injection

The supplied records do not provide the vulnerable source statement, the exact command constructed by the function, or the payload syntax. Defenders should therefore avoid relying on a narrow payload-based detection rule. A successful attack could potentially provide command execution with the privileges of the device’s web or API service, but the available evidence does not establish the service account, privilege level, or post-exploitation constraints.

Technical Notes

The NVD description identifies the affected function and parameter but does not publish a complete CVSS vector or a full exploit precondition model. The relevant technical facts are:

Product:   Ziroom ZHOME A0101
Firmware:  1.0.1.0
File:      usr/lib/lua/luci/controller/api/zrUsb.lua
Function:  pop_usb_device
Input:     path
Impact:    Command injection

Who Needs to Act

Organizations, homes, and service providers operating Ziroom ZHOME A0101 devices should act if their inventory contains firmware version 1.0.1.0. The affected component is the USB Device Management API, so devices with that feature enabled deserve priority review, particularly when their administration interface is reachable from a user, guest, wireless, or internet-facing network.

The retrieved NVD information identifies only ZHOME A0101 firmware 1.0.1.0 as affected. No additional affected versions were listed, and no fixed version was identified. Versions other than 1.0.1.0 therefore cannot be confidently classified as unaffected without vendor confirmation.

If the device cannot be upgraded or removed from service, place it on a restricted management VLAN and prevent inbound access from untrusted networks. Internet exposure should be considered unsafe until the vendor documents a fix and the installed firmware is verified.

Apply the same least-privilege principle to administrators and management systems: allow only the hosts and personnel that need to administer the device. See this least-privilege IAM review checklist for a broader access-review framework.

Why This CVSS Score?

The NVD assigns CVE-2026-101187 a CVSS base score of 9.1, which is Critical. The score reflects the severity of remotely exploitable command injection in a network-connected device. Command execution can have substantially greater impact than a limited information disclosure or denial-of-service issue because it may allow an attacker to alter configuration, access local data, pivot into adjacent networks, or establish persistence.

A complete CVSS vector was not included in the retrieved NVD record. The exact values for attack complexity, privileges required, user interaction, scope, confidentiality, integrity, and availability therefore cannot be reliably reconstructed. In particular, the authentication requirement is unknown. Use the score for prioritization, but do not infer missing vector components from the 9.1 value.

The remote attack description and command-injection impact justify urgent containment. CVSS is not an exploitation forecast. It does not establish that devices are exposed to the internet, that authentication is absent, or that exploitation has succeeded in real environments.

Has It Been Exploited?

A public disclosure is available in the GitHub repository Wlz1112/ZHOME_A0101, including a document named pop_usb_device_path_command_injection.md. The NVD description explicitly states that exploit code has been made publicly available. This supports a public exploit or PoC available assessment.

Confirmed exploitation in the wild is not established by the supplied sources. CVE-2026-101187 was not listed in the CISA Known Exploited Vulnerabilities catalog when checked. There is therefore no CISA KEV date-added date, federal remediation deadline, required-action entry, or CISA ransomware-use designation for this CVE.

The absence of a KEV entry does not prove that exploitation has not occurred. It means only that CISA had not included the vulnerability in that catalog at the time of checking. Public exploit material, remote command execution, and uncertain device exposure make containment appropriate even without confirmed active exploitation.

How Do I Know If I’m Hit?

Start with asset inventory. Identify every ZHOME A0101 device, record its firmware version, management IP address, network segment, and whether its administration or USB management API is reachable from guest networks, user VLANs, wireless clients, or the internet. A device running firmware 1.0.1.0 should be treated as affected.

The available record does not document a stable URI, HTTP method, port, or payload format. Review reverse-proxy, firewall, router, and device-management logs for unexpected requests to the device, especially requests containing a path parameter or references to USB-management functionality. Investigate unusual outbound connections, new listening services, configuration changes, and shell-like process activity from the device.

Technical Notes

A basic search across exported HTTP and network-device logs can identify candidate requests. This is a triage pattern, not a complete detection rule:

grep -Eai \
  'pop_usb_device|zrUsb\.lua|USB.{0,20}(device|mount)|[?&]path=' \
  /var/log/http* /var/log/nginx/* /var/log/haproxy/* 2>/dev/null

For a SIEM query, adapt the field names to the local schema:

(device_product:"Ziroom" OR device_model:"ZHOME A0101")
AND (
  url.query contains "path="
  OR request_uri contains "pop_usb_device"
  OR request_uri contains "zrUsb.lua"
)

If the device exposes no useful logs, monitor the network boundary for unexpected outbound DNS, HTTP, HTTPS, or other sessions originating from the device’s management IP. Do not treat the absence of matching logs as evidence that the device is clean; embedded devices frequently provide incomplete telemetry.

What Do I Do About It?

No vendor-confirmed fixed version was identified in the available material. Do not upgrade to an unspecified later version and assume remediation unless Ziroom documents that the version fixes CVE-2026-101187. Contact the vendor or distributor for an official firmware image, release notes, and a supported upgrade procedure. Preserve the current firmware and configuration before making changes where operationally appropriate.

Until a fix is confirmed, remove the device from internet exposure and restrict access to trusted administrators. If the device is business-critical and cannot be isolated, place it behind an access-control boundary that permits only required management hosts. Replace or retire the device if the vendor does not provide a supported remediation path.

If compromise is suspected, rotate device-management and network credentials from a trusted system. Organizations that need a centralized way to manage unique administrator passwords may consider a password manager such as [1Password]Try 1Password →, but its use does not replace network isolation, firmware remediation, or incident response.

For administrator access, combine restricted network reachability with strong authentication where the device and management platform support it. Phishing-resistant authentication guidance may also be useful when reviewing the security of connected-device administration.

Technical Notes

Because no official upgrade command or fixed firmware version is available, the immediate workaround is network isolation. An example Linux gateway rule that blocks traffic to a device from an untrusted interface is:

# Replace eth0, 192.0.2.25, and 192.0.2.0/24 with local values.
sudo nft add table inet cve_2026_101187
sudo nft 'add chain inet cve_2026_101187 forward { type filter hook forward priority 0; policy accept; }'
sudo nft add rule inet cve_2026_101187 forward iifname "eth0" ip daddr 192.0.2.25 ip saddr 192.0.2.0/24 drop

Use the organization’s firewall or switch ACL system if the device is not routed through a Linux gateway. Restrict both administrative access to the device and unnecessary outbound access. Do not execute an unverified firmware image or use an unofficial upgrade command; the available sources do not identify a supported Ziroom remediation package.

After Ziroom publishes a fixed release, verify the exact version and follow the vendor’s documented process. For now, the operational position is:

Affected version: 1.0.1.0
Fixed version:    Not identified
Official patch:   Not confirmed

Where This Comes From

The primary technical record is the NVD entry for CVE-2026-101187. It identifies the affected product, firmware version, vulnerable function, command-injection impact, remote attack description, and public exploit status. It also records that the vendor was contacted before disclosure but did not respond according to the supplied information.

The public disclosure is useful for defenders validating the affected code path, but testing should be limited to devices owned or authorized by the organization. A public PoC does not by itself confirm successful exploitation in the wild.

References:

• NVD: CVE-2026-101187
• Public GitHub disclosure: ZHOME_A0101 pop_usb_device path command injection
• VulDB CVE record
• VulDB submission reference
• VulDB vulnerability record
• VulDB CTI reference

No reliable EPSS percentile was supplied in the available research material; the epss_percentile frontmatter value is therefore recorded as unavailable rather than an exploitation prediction.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.