CVE-2026-2823: The NTP Field That Set the Clock and Spawned a Shell

A timestr value from a JSON config request lands in sprintf and then system() on the Comfast CF-E7, with no sanitization between the wire and the shell — a textbook command injection in a router CGI that, on this firmware, runs as root.

The advisory in plain English

CVE-2026-2823 is a remote command injection (CWE-78, OS command injection) in the Comfast CF-E7, firmware V2.6.0.9. The NVD entry points at the function sub_41ACCC inside the webmggnt CGI component, reachable through /cgi-bin/mbox-config?method=SET&section=ntp_timezone. The attacker-controlled parameter is timestr — the field a browser normally fills with a date string when you set the router's clock. CVSS 6.3 (medium); the score is held down chiefly because VulDB rated the impact metrics Low across the board (C:L/I:L/A:L), not by the authentication requirement and certainly not by any difficulty in the bug itself. The advisory is blunt about the vendor relationship: "The vendor was contacted early about this disclosure but did not respond in any way."

A note on what this repository actually is, because the honest framing matters. jinhao118/cve is not the firmware source tree and there is no fix commit to diff — Comfast shipped no patch. The repo is a disclosure archive: per-device markdown writeups plus screenshots. The "flawed function" here is an IDA Pro decompilation captured as a PNG, embedded in the writeup. So this is binary forensics wearing a source-review coat. Everything below is transcribed from artifacts I read in the cloned repo, and I'll cite each one so you can check my transcription against the same pixels and bytes.

The writeup itself states the mechanism plainly (ComFast Router_3.md @ b6c6705, L17):

"the timestr field is not validated and is concatenated using sprintf, and then executed using system, which requires that ntp not be enabled."

The flawed function

The decompilation lives in images/2026-02-07-14-59-49-image.png, added to the repo in commit 32450bb and referenced from ComFast Router_3.md. Reading that screenshot with the vision tool, the relevant tail of sub_41ACCC transcribes to:

// transcribed from images/2026-02-07-14-59-49-image.png @ 32450bb
blobmsg_parse((char *)&timestr + ..., 7, &v13, *a1 + 1, ...);
v21 = v13;
if ( v13 )
{
  v3 = v2(v17);
  if ( !atoi(v3) )                       // ntp_client_enabled == 0
  {
    v4 = v2(v21);                         // the timestr blob value
    sprintf(v12, &aDateSSDevNull[...], v4);
    system(v12);                          // <-- game over
  }
}

Three lines tell the whole story. blobmsg_parse pulls the JSON fields out of the request into a blob table. v21/v13 is the parsed timestr node; v4 is its string value, fetched through the helper v2. That value goes straight into sprintf against a format string IDA auto-labeled aDateSSDevNull, and the resulting buffer v12 is handed to system().

IDA names string symbols after their alphanumeric content, so aDateSSDevNull reconstructs — and I'm flagging this as inference from the label, not a byte I read — to something on the order of date -s "%s" >/dev/null. The single %s is the user's timestr. That is the entire data path from HTTP body to root shell: parse, format, execute. Nowhere in it is there a character allowlist, a quote-escaper, or a system-to-execve refactor that would have removed the shell from the loop.

Why the check was insufficient

There is a conditional guarding the system() call — if ( !atoi(v3) ), where v3 comes from v17. From the PoC body, v17 is the parsed ntp_client_enabled field; the writeup confirms the command "requires that ntp not be enabled." So the device only sets its clock manually (via the date shell-out) when NTP auto-sync is turned off. atoi("0") returns 0, the negation is true, and the branch fires.

This is the classic confusion between a functional precondition and a security control. The atoi gate exists so the firmware doesn't bother shelling out to date when NTP is already keeping time — it's product logic, not a defense. An attacker simply sets "ntp_client_enabled":"0" in the same JSON they're sending, which is exactly what the published PoC does (ComFast Router_3.md @ b6c6705, L56). The gate is fully attacker-controlled, so it filters nothing. The only real "validation" in the function checks whether the caller wants manual time — never whether the time string is a time string.

And timestr is never type-checked or pattern-matched. A legitimate value looks like 2021-10-10 10:10:10. The moment you append a shell metacharacter — a ;, a " to close the date argument, a | — the single command becomes several, and system() runs them all under /bin/sh. I'm deliberately not reproducing the metacharacter chain from the PoC; the lesson is the unsanitized concatenation, not the trigger string.

Impact, and why "medium" undersells it

A second screenshot in the repo (images/2026-02-07-14-56-03-image.png) shows the consequence: a listener receiving a connection from 192.168.0.1, dropping into BusyBox v1.26.2 built-in shell (ash), with id reporting uid=0(root) gid=0(root). So the CGI runs as root and the injected commands inherit that. On embedded Linux there is rarely any privilege separation between the web server and the rest of the box — root on the CGI is root on the device: traffic interception, persistence, pivoting into the LAN.

The 6.3 owes more to VulDB's Low impact subscores (C:L/I:L/A:L) than to the COMFAST_SESSIONID session requirement — and that is exactly where the number undersells the bug. A root shell is total compromise of the device's confidentiality, integrity, and availability; scoring those impacts as Low is the discrepancy this section is about. The session requirement matters too, but router admin sessions are a soft barrier: default credentials, CSRF against a logged-in admin, and the simple reality that LAN-side attackers (a guest, a compromised IoT device on the same network) often already have what they need. "Authenticated command injection to root" on a consumer AP is a high-value foothold regardless of the headline number.

What a fix would change (since there isn't one)

There is no patch to point at, so here is what one would have to do. The narrow fix is to stop building a shell command from untrusted input: replace system(v12) with a fork/execve of /bin/date passing timestr as a single argv element, so the shell never parses it. The defensive fix is input validation — reject any timestr that isn't a strict YYYY-MM-DD HH:MM:SS pattern before it goes anywhere near a buffer. Better still, set the system clock with settimeofday()/clock_settime() after parsing the fields numerically, and never shell out to date at all. Any one of those three breaks the chain; the firmware does none of them.

Because the vendor didn't respond, the practical mitigation is operational: keep the CF-E7 management interface off untrusted networks, change default credentials, and treat the admin session as the only thing standing between a LAN peer and a root shell.

The lesson

Two old lessons, both still earning CVEs in 2026. First: a precondition is not a permission check. The atoi(ntp_client_enabled) test looked like a guard but only encoded when the feature runs, using a value the attacker supplies. If the thing you're "checking" arrives in the same request as the payload, you're not validating anything. Second: sprintf + system is a code-execution primitive, not a convenience. Every time user data is formatted into a string that a shell will later parse, you have re-implemented command injection, no matter how innocuous the field name. timestr was supposed to set a clock. It set up a shell instead — because the only thing between the JSON and /bin/sh was a %s.

References

• Disclosure writeup (Comfast CF-E7): https://github.com/jinhao118/cve/blob/b6c670511adf90368e969a0b272bc8c201acf6d4/ComFast%20Router_3.md#L17
• Decompiled sub_41ACCC (IDA screenshot): https://github.com/jinhao118/cve/blob/32450bb7ca2c26c0ca0c8095a383cc7149f16d2a/images/2026-02-07-14-59-49-image.png
• PoC / root-shell screenshot: https://github.com/jinhao118/cve/blob/32450bb7ca2c26c0ca0c8095a383cc7149f16d2a/images/2026-02-07-14-56-03-image.png
• NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-2823
• VulDB: https://vuldb.com/?id.346948
• VulDB CTI: https://vuldb.com/?ctiid.346948