CVE-2026-4163: Two Doors, One `system()` — Command Injection in Wavlink's wireless.cgi

A remote, unauthenticated POST to a MIPS router's CGI turns two innocuous-looking Wi-Fi settings — a device name and a guest SSID — into arbitrary shell. One path has no input check at all; the other has a check that quietly doesn't count.

The advisory in plain English

CVE-2026-4163 (CVSS 3.1 base 9.8) affects the Wavlink WL-WN579A3 range extender, firmware build 220323, running on a MediaTek MT7628 (little-endian MIPS) SoC behind lighttpd. The vulnerable component is the POST request handler in /cgi-bin/wireless.cgi. Two handler branches — SetName and GuestWifi — take attacker-supplied strings straight out of the request body and splice them into a shell command line that is then handed to system(). No authentication is required; the device happily services the request from anyone who can reach its web port — though that web port is normally exposed only on the extender's own LAN/WLAN segment, so "remote" here means adjacent-network, not internet-wormable. The vendor's remediation is a firmware upgrade — there is no source patch to diff, because this is closed firmware and the disclosure ships as decompilation, not a pull request. My analysis below is grounded in Li Tengzheng's published IDA/Hex-Rays decompiler output for the affected binary. One thing I can't fully reconcile: the affected build is stamped 220323, but the firmware image linked in the advisory is dated 2026-03-10. Those aren't the same build, and the later image may well be the fixed remediation release rather than the vulnerable one — I couldn't fetch either to check (see below).

The firmware image referenced in the advisory is hosted on dl.wavlink.com, which is outside this sandbox's proxy allowlist (the CONNECT tunnel returns 403 Forbidden from squid), so I could not independently re-disassemble the binary. Everything that follows is transcribed from the decompiler screenshots in the disclosure repository, and I cite the exact image and function address for each block. One caveat on attribution: SetName and GuestWifi live in two separate directories of that repository — vul_9 and vul_10 — and I map both to CVE-2026-4163 on the strength of a single VulDB entry (id.351070). I was not able to confirm on NVD that the GuestWifi disclosure doesn't carry its own CVE, so treat the shared identifier as provisional; distinct injection points in distinct disclosures sometimes get distinct IDs.

The dispatcher

Everything funnels through one function the researcher labels ftext. It pulls the page field out of the POST body with a helper (sub_4053E4, effectively a "get form parameter by name" routine) and runs a strcmp ladder to pick a handler.

From WL-WN579A3/vul_9/img/ftext.png @ a7c453d:

v8 = sub_4053E4("page", v4, 0);
...
else if ( !strcmp(v8, "SetName") )   sub_403280(v4, 4259840);
else if ( !strcmp(v8, "GuestWifi") ) sub_4033CC(v4);

So page=SetName routes to sub_403280, and page=GuestWifi routes to sub_4033CC. Both are reachable pre-auth; the dispatcher never consults a session before branching. Two doors, and behind each one is the same appliance-firmware anti-pattern: build a command string with sprintf, then run it.

Door one: SetName, the unguarded path

sub_403280 reads three form fields — mac_5g, flag, and NewName — and duplicates them. NewName is the interesting one: it is fully attacker-controlled and goes nowhere near a sanitizer.

From WL-WN579A3/vul_9/img/sub_403280.png @ a7c453d:

v6 = sub_4053E4("NewName", a1, 0);
v8 = strdup(v6);
memset(v12, 0, sizeof(v12));
sprintf(v12, "/etc/lighttpd/www/cgi-bin/change_name.sh %s %s &", v5, v8);
...
sub_404850((int)v12);

v8 (the raw NewName value) is formatted, unquoted, as the second argument to a shell script invocation; v5, the duplicated mac_5g value, is the first. The buffer v12 is then passed to sub_404850, which is the actual sink:

From WL-WN579A3/vul_9/img/sub_404850.png @ a7c453d:

vsprintf(byte_41BC84, a1);
snprintf(byte_41BC84, 256, "%s 1>%s 2>&1", byte_41BC84, "/dev/null");
return system(byte_41BC84);

There it is: system() on a string that contains an unescaped, unfiltered request parameter. Because NewName is dropped into the command line without quoting and without a single character-class check, any shell metacharacter the attacker includes — a command separator, a pipe, a substitution — is interpreted by the shell rather than treated as part of a device name. The source is the NewName POST field; the sink is system(byte_41BC84) inside sub_404850; the path between them is three strdup/sprintf hops with zero validation. A nice tell that this maps to real vendor source: the error-logging call in sub_403280 prints the literal "wireless.c" and line 691, so the decompiled sub_403280 is the compiled form of a SetName handler in wireless.c.

Door two: GuestWifi, the guard that doesn't guard

The GuestWifi branch is more interesting, because someone did try to add a check — it just doesn't do what they thought. sub_4033CC reads a long list of guest-network fields (guestEn, Touchlink_En, Guest_ssid, Guest_password, EncrypType, …). The attacker-controlled Guest_ssid is duplicated into v15 and passed as the third argument to sub_406BE0:

From WL-WN579A3/vul_10/img/sub_4033CC2.png and sub_4033CC1.png @ a7c453d:

v13 = sub_4053E4("Guest_ssid", a1, 0);
v15 = strdup(v13);
...
sub_406BE0("rai1", "SSID", v15);

sub_406BE0 is a generic "run an iwpriv command" helper. It builds the command, runs a validation routine, and then — depending on the result — either logs a complaint or executes:

From WL-WN579A3/vul_10/img/sub_406BE0.png @ a7c453d:

sprintf(v8, "iwpriv %s set %s=\"%s\"", a1, a2, a3);
sleep(1);
if ( sub_406B7C(v8) == 1 )        // "Invald symbol" -> log to /dev/console, skip
    ...
else
    system(v8);                   // otherwise: execute

Why the check was insufficient

Two things conspire here. First, the SSID is wrapped in double quotes inside the template: SSID="%s". A developer looking at that likely reasoned "the value is quoted, so it's inert." But double quotes in a POSIX shell do not suppress command substitution — $( … ) and backtick expansion still fire inside them. Second, sub_406B7C is a denylist: it scans the finished command string for "invalid symbols" and, if it finds one, refuses to run and logs "utils.c":"iwpriv_cmd":55 ... have Invald symbol. One honest limitation here: I don't have a decompilation of sub_406B7C itself — no image for it appears in the disclosure repository, and it isn't in the References below — so its exact filter set is not something I can read off the source. I'm inferring that it's a denylist, and inferring which characters it misses, from two things only: the log string it emits ("Invald symbol") and the observed fact that a $( … ) payload demonstrably reaches system(). On that inference: denylists are only ever as complete as the author's imagination, and this one evidently doesn't cover the substitution metacharacters — so a value crafted around $( … ) sails past the filter and survives the double-quote wrapping, landing intact in system().

That's the whole difference between the two doors. SetName has no filter and no quoting, so even a bare command separator injects. GuestWifi has a filter and quoting, but the quoting is the wrong tool for the job and the filter is a denylist with a hole. Both terminate at system() on the same MT7628.

The lesson

This is the router-firmware bug that has been shipping for twenty years, and it keeps shipping because the fix is boring and the shortcut is easy. Both doors are the same class — CWE-78, OS Command Injection — arrived at two different ways. Three durable takeaways:

• Constructing shell strings from network input is the vulnerability, not a step toward it. If a value must reach an external program, pass it as an argv element via execve/posix_spawn, never as a substring of a line handed to system() or popen(). The shell is a parser you did not intend to expose.
• Quoting is not sanitizing. Wrapping a value in double quotes stops word-splitting and glob expansion but leaves $( ) and backticks live. If your mental model is "quotes make it safe," you have already lost.
• Denylists validate the author, not the input. sub_406B7C "worked" against every metacharacter its author thought of, which is precisely why it failed. An allowlist for an SSID — a bounded set of printable characters — would have been shorter, faster, and closed both the substitution and separator classes at once.

Two handlers, one sink, and a guard that guarded the wrong door. Upgrade the firmware; the PoC is public and the CVSS is not being generous.

References

• NVD — CVE-2026-4163: https://nvd.nist.gov/vuln/detail/CVE-2026-4163
• CWE-78 — Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'): https://cwe.mitre.org/data/definitions/78.html
• Disclosure (SetName) — WL-WN579A3/vul_9/README.md: https://github.com/Litengzheng/vul_db/blob/a7c453db9ed5b9a27ff1308335c439e14a1c0ca1/WL-WN579A3/vul_9/README.md
• Disclosure (GuestWifi) — WL-WN579A3/vul_10/README.md: https://github.com/Litengzheng/vul_db/blob/a7c453db9ed5b9a27ff1308335c439e14a1c0ca1/WL-WN579A3/vul_10/README.md
• Decompiler — dispatcher: https://github.com/Litengzheng/vul_db/blob/a7c453db9ed5b9a27ff1308335c439e14a1c0ca1/WL-WN579A3/vul_9/img/ftext.png
• Decompiler — sub_403280: https://github.com/Litengzheng/vul_db/blob/a7c453db9ed5b9a27ff1308335c439e14a1c0ca1/WL-WN579A3/vul_9/img/sub_403280.png
• Decompiler — sub_404850 (sink): https://github.com/Litengzheng/vul_db/blob/a7c453db9ed5b9a27ff1308335c439e14a1c0ca1/WL-WN579A3/vul_9/img/sub_404850.png
• Decompiler — sub_4033CC / sub_406BE0 (sink): https://github.com/Litengzheng/vul_db/blob/a7c453db9ed5b9a27ff1308335c439e14a1c0ca1/WL-WN579A3/vul_10/img/sub_406BE0.png
• VulDB entry: https://vuldb.com/?id.351070
• Affected firmware (dated 2026-03-10, later than build 220323 — possibly the fixed image rather than the vulnerable one; blocked by sandbox proxy at analysis time): https://dl.wavlink.com/firmware/RD/WINSTAR_WN579A3-A-2026-03-10-94f93d4-WO-mt7628-squashfs-sysupgrade.bin