Overview
A critical, unauthenticated OS command injection vulnerability has been disclosed in Wavlink WL-WN530BE2-A consumer/SMB wireless routers. Tracked as CVE-2026-110957 and published on October 15, 2026, the flaw carries a CVSS 3.1 base score of 10.0 — the maximum possible score, reserved for issues that are remotely exploitable, require no authentication or user interaction, and threaten complete loss of confidentiality, integrity, and availability.
The vulnerability lives in the Login Processing component of api.cgi, specifically in a function identified as sub_12580 in disassembly of the firmware binary. By manipulating the REMOTE_ADDR value that the device trusts when processing a login-related API request, a remote attacker can inject arbitrary operating-system commands that execute with the privileges of the router's web-management process — without ever authenticating. All firmware builds up to and including M30BE2_V250604 are affected.
Technical Details
| Field | Value |
|---|---|
| CVE ID | CVE-2026-110957 |
| Severity | Critical — CVSS 3.1: 10.0, CVSS 4.0: 9.3 |
| Attack Vector | Network |
| Authentication | None Required |
| Privileges Required | None |
| User Interaction | None |
| Impact | Unauthenticated OS command injection (full device compromise) |
| Vulnerable Component | api.cgi → sub_12580 (Login Processing) |
| CWE Classification | CWE-78 (OS Command Injection), CWE-77 (Improper Neutralization of Special Elements used in a Command) |
CVSS 3.1 vector as recorded by vulnerability-intelligence trackers: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Note the Scope: Changed (S:C) component — the vulnerable component and the impacted component differ, consistent with a web-management process that, once compromised, can affect the entire router operating system rather than staying confined to the CGI process itself.
How It Works
api.cgi on the WL-WN530BE2-A exposes an info API action (reachable as api=info&client=app) that is part of the device's login/session-handling flow. According to a publicly documented analysis of the binary, the handler retrieves the client's apparent source address via getenv("REMOTE_ADDR") and stores it in a local variable before using sprintf() to build a shell command — observed as something resembling applogin.sh add <address> — with no validation, escaping, or allow-listing of the address value.
Because REMOTE_ADDR is treated as attacker-controlled input rather than a server-generated fact, and is concatenated directly into a string that is subsequently handed to a command-execution call (consistent with system()), an attacker can supply shell metacharacters (for example ;, `, or |) inside the value used for that field and have arbitrary commands execute in that context. In practice, this means a single crafted HTTP request to api.cgi — no login, no session token, no prior interaction with the device — is sufficient to achieve remote code execution:
- Unauthenticated request — The attacker sends a request to
api.cgiinvoking the login/info processing path (api=info&client=app), which does not require a valid session. - Controlled input reaches a dangerous sink — The value treated as
REMOTE_ADDRflows, unsanitized, into thesub_12580login-processing logic in theapi.cgibinary. - String built unsafely —
sprintf()concatenates that value into a shell command string intended to invoke a helper script (applogin.sh). - Command executes — The resulting string is executed by the device's shell, running the attacker's injected commands with the privileges of the web-management process — typically root on embedded router firmware.
Impact Assessment
Who Is At Risk
- Any WL-WN530BE2-A device running firmware M30BE2_V250604 or earlier, whether the router is sitting on a home LAN or deployed in a small-business setting
- Devices with remote/WAN administration enabled, which are directly exploitable from the public internet with zero prior access
- Devices reachable only from the LAN side are still at risk from any already-compromised endpoint on that network, from a malicious insider, or from drive-by/CSRF-style attacks that reach the router's internal IP from a victim's browser
- Consumer and SMB networking gear of this class is frequently internet-exposed, rarely monitored, and often left running factory firmware for years — exactly the conditions that let a maximum-severity, zero-authentication bug like this persist at scale long after disclosure
Potential Attack Chain
- Discovery — Attacker scans for internet- or LAN-exposed Wavlink devices (banner/fingerprint on the management web UI, or mass-scanning known Wavlink CGI paths).
- Exploitation — Attacker sends a single crafted request to
api.cgi's login/info handler with a malicious value in place of the expectedREMOTE_ADDR. - Command Execution — The injected shell command executes on the device with web-process privileges (commonly root on embedded Linux router firmware).
- Persistence and Pivoting — Attacker plants a persistence mechanism (modified startup script, added cron-like job, or binary implant), disables logging, and uses the router as a foothold to intercept, redirect, or man-in-the-middle all LAN traffic passing through it.
- Full Network Compromise — From a compromised router, the attacker can pivot to internal hosts, harvest credentials from unencrypted LAN traffic, add the device to a botnet, or use it as an anonymizing relay for further attacks.
Mitigation
Immediate Actions
- Check the vendor's firmware for an update before doing anything else. Multiple vulnerability-intelligence sources (VulDB, Strix) independently report that Wavlink has confirmed this issue and shipped a fix — described as replacing the vulnerable
system()-based shell-command construction with anexecvp()-based argument vector, plus length-limiting and null-checking the client-address value — in a firmware build referenced as2026-09-24-841a51c6d5_tclinux.bin, distributed from Wavlink's own download servers. CosmicBytez Labs has not independently downloaded, hashed, or verified this firmware build, and Wavlink has a documented history of leaving EOL consumer router models unpatched — so treat this as a reported, not confirmed-by-us, fix. Obtain any update directly from Wavlink's official site, verify the version string againstM30BE2_V250604and the patched build identifier above, and do not trust third-party mirrors. - If no verified patch is available for your specific hardware revision, disable remote/WAN administration immediately and do not expose the router's management interface to the internet under any circumstances.
- Place the device behind an additional firewall or replace it with a non-affected router if it must remain in a security-sensitive environment and a verified patch cannot be confirmed.
- Change default credentials and disable unused management services (UPnP admin, remote CGI access) as general hardening regardless of patch status.
- Consider retirement of this device class for any deployment where the vendor's EOL/patch posture cannot be independently verified — a maximum-CVSS, unauthenticated RCE bug is not one to leave to assumption.
Detection Opportunities
- Monitor router/WAN-facing logs (where logging exists) for unusual requests to
api.cgi, especially withapi=infoandclient=appparameters combined with unexpected header values. - Watch for unexpected outbound connections, DNS changes, or new persistent processes originating from the router itself — difficult on stock firmware, but visible via upstream network monitoring (NetFlow/firewall logs showing the router's WAN IP making anomalous outbound calls).
- Flag any firmware version string reporting
M30BE2_V250604or earlier in asset inventory/scanning tools as vulnerable pending verified remediation.
Defence-in-Depth
- Segment IoT and consumer networking gear onto its own VLAN, isolated from sensitive internal hosts, so a compromised router cannot directly pivot to critical systems.
- Disable remote administration on all consumer/SMB routers by default; require VPN access for any legitimate remote management need.
- Maintain an inventory of network edge devices and their firmware versions, and subscribe to vendor and CVE feeds for the hardware you deploy rather than assuming "set and forget."
Background
Command-injection flaws in embedded router CGI handlers follow a recurring pattern: a value that looks like it should be trustworthy — here, the client's own REMOTE_ADDR — is treated as safe input and concatenated into a shell command with no sanitization. Because these CGI binaries typically run with root privileges and sit at the network edge, a single unauthenticated request is often enough to go from "attacker on the internet" to "root on the router" in one step. Consumer and SMB router firmware is also notorious for multi-year gaps between disclosure and patching — and in some cases, no patch at all once a model reaches end-of-life. Whatever Wavlink's response turns out to be for this specific CVE, the underlying lesson holds: internet-facing embedded devices with CGI-based management interfaces deserve the same scrutiny as any other internet-facing server, and network administrators should not assume vendor remediation will arrive before exploitation does.