CVE-2026-1802: When `os.execute` Met an HTTP Form Value

A Ziroom ZHOME A0101 router ships its mac-clone admin endpoint with a Lua "logger" that pastes the user's POST body straight into a shell command — and then leaves the debug flag turned on by default. The fix never landed: the vendor was contacted and went silent.

The advisory in plain English

CVE-2026-1802 is a post-auth remote command injection in the Ziroom ZH-A0101 ("ZHOME A0101", firmware 1.0.1.0), a consumer router that ships an OpenWrt/LuCI web stack. The vulnerable handler is reachable at:

POST /cgi-bin/luci/;stok=<token>/api/ZRMacClone/mac_addr_clone

The session token (stok=...) means an attacker needs a logged-in session — the LuCI route declares page.sysauth = "root" (visible in the source screenshot in the disclosure repo at images/2026-01-18-16-41-36-image.png). On stock firmware that is "the user", since SOHO routers have exactly one human account. So this is "authenticated" the way most router CVEs are authenticated: any recovered default credential reduces the bar to zero.

The disclosure repo is https://github.com/jinhao118/cve (commit aebfec0, file ziru_router_command_injection.md, dated 2026-01-18). The NVD entry notes the vendor "did not respond in any way," so there is no upstream patch — the entire write-up is built off the unmodified production source captured in two screenshots inside the disclosure repo. That source is what the rest of this post quotes from.

The flawed module

The module preamble lives in luci/controller/api/zrMacClone.lua. Excerpted from the screenshot in the disclosure repo at images/2026-01-18-16-41-36-image.png:

module("luci.controller.api.zrMacClone", package.seeall)

function index()
    local page = node("api","ZRMacClone")
    page.target = firstchild()
    page.sysauth = "root"
    page.sysauth_authenticator = "jsonauth"
    ...
    entry({"api","ZRMacClone","mac_addr_clone"}, call("macAddrClone"), (""), 401)
end

local g_debug = true

local outlog = '/tmp/mac_clone.log'
local function logger(msg)
    os.execute('echo "' .. msg .. '" >>' .. outlog)
end

(For non-LuCI readers: the trailing 401 in entry() is LuCI's entry order, not an HTTP status; jsonauth is the JSON-RPC-style session validator.)

There are three separate decisions in those nine lines, and each one is a paper cut that becomes a knife in combination:

1. g_debug = true — a debug flag is hard-coded true at module scope in shipping firmware. No environment lookup, no nixio check, no comment-out for release. Whatever this flag gates is always on.
2. logger shells out — instead of using Lua's io.open(outlog, "a"):write(...) to append, the author wraps echo and pipes it through os.execute. So "log this string" is implemented as "run a shell with this string concatenated in."
3. No escaping — msg is interpolated into the command with ... The author closes the literal with a " and writes 'echo "' .. msg .. '" >>' .. outlog. Any closing quote, semicolon, or backtick inside msg exits the echo.

Each one of those is a smell. Together they are an unfenced sshd waiting for a destination string.

The trigger function

The actual handler reachable from the network is macAddrClone. Excerpted from the screenshot in the disclosure repo at images/2026-01-18-16-44-26-image.png:

function macAddrClone()
    LuciHttp.prepare_content("application/json")
    local macType = LuciHttp.formvalue("macType")

    --local result = {code=0}
    if g_debug then logger(macType) end

    local cmd = "uci -q get network.wan.ifname 2>/dev/null"
    local dev = ZRMacFun.trim(LuciUtil.exec(cmd))
    ...

(For the unfamiliar: LuciHttp and LuciUtil are the standard LuCI modules — require "luci.http" and require "luci.util" — while ZRMacFun is a vendor helper.)

Line by line, with my hands kept behind my back so this stays a description of the defect and not a recipe:

• LuciHttp.formvalue("macType") pulls the raw macType POST field. LuCI's formvalue does not sanitize — it just decodes URL escaping and hands you the bytes the client sent.
• The result is bound to macType with zero validation. Context in the surrounding source indicates macType is a mode selector, but the code never enforces that — formvalue returns whatever bytes the client sent.
• if g_debug then logger(macType) end — and since g_debug is permanently true, this is unconditional. The attacker's bytes go straight into the echo "<bytes>" >> /tmp/mac_clone.log shell command from the previous section.

The "trigger input" is therefore any string containing a shell metacharacter — a closing quote to break out of the echo argument, a semicolon to start a new command, and anything that doesn't leave a dangling token at the end. The disclosure write-up shows a reverse-shell payload doing exactly that and netcat catching a root shell on the attacker's listener. I'm not going to reprint the payload string here; it's two lines down from this paragraph in the source repo if you really want to read it, and it's a perfectly ordinary ;<shell>;# shape.

Why a "logger" became RCE

This is one of those bugs where the security model isn't subtly wrong, it just isn't there. Three failure modes worth naming:

Shell-as-string-builder. os.execute('echo "' .. msg .. '" >>' .. outlog) is the canonical anti-pattern. Lua doesn't have a shellescape, and os.execute is a wrapper around system(3), which spawns /bin/sh -c <string> — on OpenWrt that shell is BusyBox ash, which still honors ;, &&, and quote-breaking. Any string concatenation into that argument is one well-placed " away from arbitrary command execution. This is the textbook shape of CWE-78 (Improper Neutralization of Special Elements used in an OS Command). The general defense is argv-vector exec — e.g. nixio.fork() and then nixio.exec(prog, arg1, ...) in the child (bare nixio.exec wraps execv and would replace the LuCI handler process), or a higher-level helper like luci.util.execl that takes argv as separate arguments. Either way the shell never sees a concatenated string. The native fix here would be three lines: open the log file with io.open(outlog, "a"), write(msg .. "\n"), close(). No shell, no concatenation, no problem.

Debug code on the production path. g_debug = true at module load means there is no environment in which this code branch is dormant. Production firmware should ship with debug paths either compiled out or disabled by default. A grep across the firmware for g_debug is, sadly, often educational — once one module establishes the pattern, others copy it, and you end up with a constellation of "only triggered if debug" sinks that are always on.

No input typing at the boundary. macType is supposed to be a small integer. The handler treats it as an opaque string. Lua's lack of static types is not the excuse it appears to be — tonumber(LuciHttp.formvalue("macType")) returns nil for anything that isn't a number, and a one-line guard would have killed this. The boundary between "bytes from the network" and "values inside our program" is the most important boundary in any web handler, and this one didn't have one.

What the fix would have changed (and didn't)

There is no upstream fix. Per NVD: "The vendor was contacted early about this disclosure but did not respond in any way." The disclosure repo (jinhao118/cve, the one I cloned) is not the vendor's tree — it is the researcher's writeup directory, with no patch artifact, no diff, no before/after pair. I checked git log --all --grep=ziru and got back exactly one commit, the file rename. There is no Fix command injection in macAddrClone commit to point at, because there is no fix.

What a competent fix would have done, on any line of defense:

• Replaced os.execute('echo "' .. msg .. '" >>' .. outlog) with file-IO (io.open, write, close). Removes the shell entirely.
• Set g_debug = false, or removed the logger(macType) call from the handler.
• Coerced macType to a numeric type and rejected anything outside the expected mode set at the top of the handler.
• Used an argv-taking spawn helper (luci.util.execl with separate arguments, or nixio.fork() + nixio.exec in the child) anywhere a subprocess is needed, never luci.util.exec or os.execute with a built-up command string.

Any one of those by itself ends the bug. Defense in depth would mean all four. From the source we can see, the vendor shipped zero.

The lesson

If you build commands with .. (or +, or format, or any string operator), you have a shell-injection bug — the only question is whether the input ever reaches a user. "Log this for me" is not a permission to invoke a shell. And a g_debug constant set to true in a release tree is not a debug flag, it's a production feature with terrible ergonomics.

The depressing part of CVE-2026-1802 isn't the bug itself — os.execute with string concat is a senior-engineer-on-Monday-morning bug. The depressing part is the vendor silence. With no patch, the population of vulnerable devices on the public internet doesn't shrink; it just ages. Authenticated-only is comforting until you remember that default credentials collapse "authenticated" into "any visitor who can read the sticker on the bottom of the box."

If you're inheriting Lua/LuCI code, grep for os.execute and LuciUtil.exec taking concatenated strings. Then grep for _debug = true. Then go to lunch — you'll be busy.

References

• NVD entry: https://nvd.nist.gov/vuln/detail/CVE-2026-1802
• Researcher writeup: https://github.com/jinhao118/cve/blob/main/ziru_router_command_injection.md
• VulDB: https://vuldb.com/?ctiid.343975
• VulDB submission: https://vuldb.com/?submit.741842
• Cloned commit examined: aebfec0 of github.com/jinhao118/cve