CVE-2026-102793: Ziroom ZHOME Command Injection
TL;DR - CVE-2026-102793 is a critical command-injection flaw in Ziroom ZHOME A0101 firmware version 1.0.1.0. - The vulnerable endpoint is
/api/ZRFirmware/set_time_zone; authentication requirements are not confirmed across deployments. - Public exploit material exists, but CISA KEV does not currently confirm in-the-wild exploitation. - No verified vendor patch or fixed firmware version has been identified. Isolate affected devices and investigate suspicious access.
Summary
CVE-2026-102793 affects Ziroom ZHOME A0101 firmware version 1.0.1.0. The vulnerability is a form of command injection in the set_time_zone functionality exposed at /api/ZRFirmware/set_time_zone.
Manipulating the hostname or zonename argument can reach command-processing logic and result in remote command execution. NVD reports a CVSS base score of 9.1, rated critical. The available record does not identify a verified vendor patch or fixed firmware release.
Treat version 1.0.1.0 as vulnerable, and assume exposure where the device API is reachable from an untrusted network.
| Field | Details |
|---|---|
| CVE ID | CVE-2026-102793 |
| CVSS score | 9.1, Critical |
| Attack vector | Network |
| Authentication required | Not confirmed in the primary record; a secondary vector indicates high privileges required |
| Patch available | No verified vendor patch or fixed version identified |
| Affected product | Ziroom ZHOME A0101 |
| Affected version | 1.0.1.0 |
| Vulnerable function | set_time_zone |
| Endpoint | /api/ZRFirmware/set_time_zone |
The authentication field requires care. The secondary CVSS attribution indicates PR:H, meaning high privileges are required in that assessment, but the retrieved NVD record does not establish how authentication is enforced in every deployment. Administrators should test access controls in their own environment instead of assuming the endpoint is either public or safely authenticated.
Analyst’s Take: The first operational question is whether version 1.0.1.0 can reach an untrusted network, not whether CISA has listed the CVE. No verified fix is available, and authentication requirements remain unclear across deployments, so isolation and access-control testing should precede deeper validation.
Root Cause
The root cause is improper handling of attacker-controlled input in the hostname or zonename argument accepted by the set_time_zone function. The input is apparently passed into command-processing logic without sufficient validation, escaping, or use of a safe argument-handling API.
As a result, the operation permits command injection instead of limiting input to a valid hostname or time-zone value.
This is an application-layer flaw in a device management API, but its impact depends on the privileges of the service handling the request. Successful exploitation could allow arbitrary commands to run on the device, potentially affecting:
- Device configuration
- Stored data
- Device availability
- Credentials
- Outbound network behavior
- Neighboring systems reachable from the device
The available evidence does not establish the exact operating-system account or process privileges. Defenders should therefore investigate the device as potentially compromised after suspicious requests.
Technical Notes
The exposed route identified in the vulnerability record is:
/api/ZRFirmware/set_time_zone
The vulnerable parameters are reported as:
hostname
zonename
Do not test exploit payloads against production devices. For authorized validation, first confirm the firmware version and API access controls in an isolated lab or through a vendor-approved assessment process.
Who’s Exposed
The specifically identified affected product is Ziroom ZHOME A0101 running version 1.0.1.0. No additional ZHOME versions or other Ziroom products were identified in the reviewed NVD record.
Because the available disclosure does not provide a broader affected-version interval, administrators should not extrapolate the impact to other firmware versions without vendor confirmation.
Devices face the greatest practical risk when their management interface or API is reachable from:
- The public Internet
- Guest networks
- Shared residential networks
- Untrusted internal segments
- Networks where administrative credentials may already be compromised
A device may still be exposed internally if an attacker can obtain the privileges required by the deployed API configuration. Network isolation reduces reachability, but it does not remove the need to investigate devices that have already received suspicious requests.
| Product | Affected version range | Fixed version |
|---|---|---|
| Ziroom ZHOME A0101 | 1.0.1.0 | No verified fixed version identified |
| Other Ziroom products | Not identified | Not applicable |
Inventory teams should collect the product model, firmware version, management IP address, exposure path, and administrative ownership for every deployed unit.
When the version cannot be determined remotely, use the device’s management interface or an approved vendor procedure. Do not infer safety from a missing version banner.
Severity Breakdown
NVD reports a CVSS score of 9.1, which places the issue in the critical category. A secondary search result attributes the following vector:
CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H/E:P/RL:X/RC:C
Treat the vector as secondary-source context because the retrieved NVD record supplied the score but did not expose the vector directly.
Its components describe a network-reachable flaw with low attack complexity, high privileges required, no user interaction, changed scope, and high confidentiality, integrity, and availability impact.
| CVSS component | Reported interpretation |
|---|---|
| AV:N | Exploitable over a network |
| AC:L | Low attack complexity |
| PR:H | High privileges required, according to the secondary attribution |
| UI:N | No user interaction required |
| S:C | Impact crosses a security authority boundary |
| C:H | High confidentiality impact |
| I:H | High integrity impact |
| A:H | High availability impact |
| E:P | Public exploit code or exploit material available |
| RL:X | Remediation level not specified |
| RC:C | Confirmed confidence in the secondary vector attribution |
The high-privilege requirement may reduce unauthenticated Internet exploitation, but it does not make the flaw low risk. Compromised administrative credentials, weak access controls, exposed management services, or lateral movement can satisfy that prerequisite.
The public exploit reference and lack of a verified fix add operational urgency.
Exploitation Status
A public exploit or proof-of-concept reference exists. The NVD description states that “the exploit has been published and may be used,” and the NVD references a GitHub document titled set_time_zone_hostname_command_injection.md.
The referenced material is available at:
https://github.com/waltz-sketch/Ziroom/blob/main/set_time_zone_hostname_command_injection.md
The existence of the reference is established by the supplied record, but the complete rendered technical content was not independently validated in the review. Defenders should verify the repository through their normal threat-intelligence and software-reputation processes. Do not copy exploit instructions into production testing.
Confirmed exploitation in the wild has not been established by the reviewed sources. CISA does not list CVE-2026-102793 in its Known Exploited Vulnerabilities catalog at the time of review.
There is no CISA remediation deadline, ransomware-campaign designation, or CISA-confirmed exploitation claim. This status can change; the absence of a KEV listing is not evidence that affected devices are safe.
Sources
The primary technical reference is the NVD record for CVE-2026-102793:
The public exploit-material reference identified in the record is:
The NVD-associated VulDB reference is:
The VulDB page was not independently verified during the review because the request returned HTTP 403. Treat it as a supplementary reference rather than the basis for affected-version or remediation claims.
Ziroom’s security response center is:
As of the review date, no official Ziroom advisory confirming a fixed version was identified. CISA KEV status was also checked for this assessment and was not listed.
That finding limits claims about confirmed exploitation, but it does not reduce the need to isolate version 1.0.1.0 and investigate suspicious access to the vulnerable endpoint.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection Guidance
Start by searching HTTP access logs, reverse proxies, API gateways, and firewall telemetry for requests to /api/ZRFirmware/set_time_zone.
Pay particular attention to requests containing hostname or zonename parameters alongside shell metacharacters, command separators, substitutions, or unexpected whitespace. URL decoding may be required before searching, depending on the logging format.
A useful generic detection query for a normalized HTTP log source is:
http.request.uri.path == "/api/ZRFirmware/set_time_zone"
AND (
url.query contains "hostname="
OR url.query contains "zonename="
)
AND (
url.query contains "%3B"
OR url.query contains "%7C"
OR url.query contains "%26"
OR url.query contains "%24"
OR url.query contains "%60"
OR url.query contains "../"
)
This is a triage rule, not a complete exploit signature. Legitimate time-zone administration may generate requests to the same endpoint, and attackers may use encoding or request formats not covered by the query.
Correlate the source address, authenticated account, device response code, request timing, and subsequent device behavior.
Technical Notes
Example web-server search after exporting and URL-decoding relevant fields:
grep -E '/api/ZRFirmware/set_time_zone' access.log \
| grep -Ei 'hostname=|zonename=' \
| grep -Ei '%3b|%7c|%26|%24|%60|;|\||&&|\$\('
Also investigate device-side indicators where available:
- Unexpected administrative or firmware configuration changes
- New outbound connections from the device
- Repeated requests to the vulnerable endpoint from unfamiliar internal hosts
- Processes or services that restart without a scheduled maintenance event
- DNS, NTP, or time-zone changes that do not match approved administration
- Authentication events involving previously unused accounts or source networks
Preserve logs before rebooting or resetting a suspected device. A factory reset may destroy useful evidence, and it does not prove that the firmware or management configuration is safe.
Remediation Steps
No vendor-confirmed patch or fixed version was identified for CVE-2026-102793. The affected version is 1.0.1.0, so there is no verified upgrade target to provide.
Contact Ziroom through its security response center at https://zrsecurity.ziroom.com and request a remediation release or vendor-approved mitigation. Do not treat an unrelated firmware update as a fix unless Ziroom confirms that it addresses this vulnerability.
Until a verified fix is available:
- Remove direct Internet exposure.
- Restrict the management/API interface to a dedicated administration network.
- Apply firewall or router ACLs to block untrusted source networks.
- Place the device on a management VLAN where practical.
- Review access logs for suspicious requests.
- Rotate credentials used to administer the device.
- Monitor neighboring systems for lateral movement.
- Disconnect the device if it cannot be isolated and is not operationally required.
If administrators need remote access to a protected management network, use an approved enterprise VPN rather than exposing the device API directly. Consumer VPN services such as Check NordVPN pricing → may be useful for personal privacy, but they should not replace an organization’s properly managed remote-access architecture.
After containment, store new administrative credentials in an approved password manager such as Try 1Password →, if permitted by organizational policy. Credential storage does not remediate the vulnerability, but it can reduce reuse and improve the quality of the credential-rotation process.
Technical Notes
A Linux gateway example that blocks external access to the endpoint while allowing a trusted management subnet must be adapted to the actual interface and traffic path:
sudo iptables -A FORWARD -p tcp -s 0.0.0.0/0 -d <DEVICE_IP> \
--dport 80 -m string --string "/api/ZRFirmware/set_time_zone" --algo bm -j DROP
String matching at the firewall is imperfect and may not inspect encrypted traffic or all request forms. A stronger workaround is to deny all inbound access to the device from untrusted networks and permit only the administration subnet:
sudo iptables -A FORWARD -s <TRUSTED_ADMIN_SUBNET> -d <DEVICE_IP> -j ACCEPT
sudo iptables -A FORWARD -s 0.0.0.0/0 -d <DEVICE_IP> -j DROP
Before applying rules, confirm the device address, management protocol, and gateway policy so the change does not disrupt required safety or building functions.
If a vendor releases a fixed firmware version, record the exact version and use the vendor’s documented upgrade process. Do not fabricate or infer a fixed version from a generic firmware number.
If suspicious command execution is found, treat the device as compromised and follow the organization’s incident-response process. For broader preparation, review this guide to the first hour of a ransomware attack, particularly the sections on containment, evidence preservation, and credential protection.