Skip to content
eastbaycyber

CVE-2026-120279: Critical WAVLINK Router Flaw

CVSS · Critical
10.0
In CISA KEV
No
Published
Nov 2
Patch SLA & TriageVector: Network
24 to 48 hours

Critical CVSS (10.0) reachable over network.

Exposure:
Control:
CVSS v3.1 Blast RadiusScore: 10.0
Decode Vector & Sub-Scores →
CVE explainers 9 min read
Security Research Desk Source-checked
Auto-checked against the official CVE record · Human-reviewed after publishing · Updated 2026-11-02
▲ Escalation ViewOne CVE, briefed at three altitudes — skim the Brief, weigh the Impact, or work the Runbook. The way a SOC actually reads it.
CISOBrief · 30-second brief

TL;DR - CVE-2026-120279 is a CVSS 10.0 remote OS command-injection flaw affecting WAVLINK WN536AX6-A firmware V260507. - Public exploit material exists, but no fixed firmware version or confirmed in-the-wild exploitation has been identified. - Immediately remove affected routers from unnecessary WAN exposure, check for an official fix, and investigate suspicious /protocol.csp requests.

CVE-2026-120279 affects the WAVLINK WN536AX6-A wireless router running firmware V260507. The vulnerability is associated with the openvpn_cli handler in /protocol.csp, where manipulation of the file_id argument may enable operating-system command injection.

Organizations managing network appliances should also review related router security guidance and assess whether exposed devices require replacement or additional access controls.

AnalystImpact · assess the risk

Are You Affected?

The confirmed affected product is the WAVLINK WN536AX6-A wireless router running firmware V260507.

Field Details
CVE CVE-2026-120279
Product WAVLINK WN536AX6-A
Affected version Firmware V260507
CVSS 10.0, Critical
Attack vector Remote
Authentication Not stated in the supplied CVE data; do not assume authentication is required
Vulnerability type OS command injection
Affected component openvpn_cli handler in /protocol.csp
Patch available No confirmed fixed version identified
CISA KEV Not listed at the time of review

The available record identifies V260507, but it does not establish a complete affected range. Defenders should not infer that every WN536AX6-A firmware version is vulnerable or treat an unverified newer release as safe. Inventory all WN536AX6-A devices, record their firmware versions, and compare them with an official WAVLINK support notice or firmware release statement.

The authentication field is also unresolved. The record describes the issue as remotely exploitable, but the supplied data does not provide the exact request flow or state whether a valid session is required. Until that detail is verified, assess internet-exposed devices as high risk and restrict access to management and OpenVPN-related functionality.

Analyst’s Take: The immediate priority is exposure reduction, not guessing whether an unverified firmware release is safe. The record confirms V260507 as affected, while the authentication requirement and complete affected range remain unresolved.

The Fix, If You’re in a Hurry

No fixed firmware version is identified in the available NVD information or supplied reference material. Do not claim that a particular release resolves CVE-2026-120279 unless WAVLINK explicitly confirms it. Contact WAVLINK support or consult its official firmware channels for a security update applicable to the WN536AX6-A.

Until an official fix is available and validated:

  • Remove affected devices from direct internet exposure wherever possible.
  • Place administration interfaces behind a VPN or dedicated management network.
  • Block unsolicited WAN access.
  • Disable OpenVPN CLI functionality if the device supports that control.
  • Replace the router if these mitigations cannot be implemented reliably.

For organizations evaluating secure remote-access products, compare requirements carefully in this VPN comparison for small businesses. A separate VPN service does not patch a vulnerable router, but it may help reduce direct exposure when deployed correctly.

Technical Notes: Immediate Mitigation

A generic network-control example using nftables is shown below. Adapt interface names and management networks to the device architecture; this command does not patch the router itself.

# Example Linux edge firewall policy:
# Permit management only from the trusted administration subnet.
nft add rule inet filter input iifname "wan0" ip saddr != 192.0.2.0/24 tcp dport 443 drop
nft add rule inet filter input iifname "wan0" tcp dport 443 drop

The exact management port and protocol exposed by a WAVLINK deployment must be confirmed before applying firewall rules. Preserve the existing configuration before making changes, and verify that the device is no longer reachable from untrusted networks using an authorized external scan.

For a device suspected of compromise, isolate it first. Preserve available logs and configuration data, reset administrative credentials from a trusted system, and reflash only with firmware obtained through an official WAVLINK channel. If a trusted firmware fix cannot be confirmed, replacement is the safer remediation path.

How This Vulnerability Works

CVE-2026-120279 involves the handling of the file_id argument by the openvpn_cli handler in /protocol.csp. The CVE description states that manipulating this argument can produce OS command injection. In practical terms, attacker-controlled input may be passed into a command-execution path without sufficient validation, escaping, or safe argument handling.

If the vulnerable process executes the resulting command, an attacker could potentially run operating-system commands on the router with the privileges of that process. The impact could include configuration changes, credential theft, traffic redirection, persistence, denial of service, or use of the router as a foothold into connected networks. The actual impact depends on process privileges, filesystem protections, network reachability, and the command path used by the firmware.

The available sources do not identify the exact vulnerable function, command, request syntax, required privilege level, or whether shell metacharacters are involved. They also do not provide a vendor-confirmed root-cause analysis or patch diff. Those gaps matter when designing precise detection rules, so defenders should avoid assuming a particular exploit payload or HTTP method.

Technical Notes: Input-to-Command Execution Risk

Conceptually, unsafe handling can resemble the following pattern:

// Illustrative only; not a reconstruction of the WAVLINK firmware.
char command[512];

snprintf(command, sizeof(command),
         "/usr/bin/openvpn-helper --file %s", file_id);

system(command);

A secure implementation would avoid shell interpretation, validate the value against an allowlist, and pass arguments through a safe process-execution interface. This example is explanatory only and should not be treated as proof of the router’s implementation.

Severity, Explained

The CVE carries a CVSS base score of 10.0, classified as Critical. The reported characteristics are consistent with a vulnerability that can be reached remotely and may allow command execution on an affected network appliance. A router is a high-value target because it controls traffic flows, DNS settings, administrative access, and connectivity between internal and external networks.

The supplied NVD result does not expose the complete CVSS vector string. Therefore, the exact values for attack complexity, privileges required, user interaction, scope, confidentiality, integrity, and availability should be confirmed directly in the authoritative CVE or NVD record before being used in automated risk scoring. The authentication requirement is not stated in the supplied data.

Even without the full vector, the operational risk is clear. Remote command injection on an edge device can enable attackers to alter routing or DNS behavior, collect credentials, redirect users, disrupt connectivity, or pivot toward internal systems. Public exploit material further reduces the effort required for opportunistic attacks.

Is It Being Exploited?

NVD states that exploit material has been published and may be used. The supplied primary reference is a GitHub technical write-up:

https://github.com/pipiyyb/cve/blob/main/WAVLINK%20WN536AX6-A/WN536AX6-A_file_id.md

This establishes that public exploit-related material exists. It does not, by itself, establish that the material is reliable, weaponized at scale, or being used by a known threat actor. The retrieved reference did not provide a complete machine-readable rendering of the technical content, so the exact exploit request and reliability could not be independently confirmed from the supplied information.

CVE-2026-120279 was not listed in the CISA Known Exploited Vulnerabilities catalog at the time of review. There is consequently no CISA KEV date-added date, due date, required action, or ransomware-campaign designation. The absence of KEV inclusion is not evidence that exploitation cannot occur. Given the CVSS 10.0 rating, remote attack surface, command-injection impact, and public exploit material, organizations should assume that internet-exposed devices may attract scanning or attempted exploitation.

ResponderRunbook · act now

Detecting It in Your Environment

Begin with asset discovery. Identify every WN536AX6-A device, collect its firmware version, determine whether its management interface or OpenVPN functionality is reachable from untrusted networks, and record administrative access paths. Network-management systems, DHCP inventories, wireless-controller records, and external attack-surface scans may all help locate devices that are not present in the standard endpoint inventory.

Review router logs, reverse-proxy records, upstream firewall telemetry, and packet captures for requests to /protocol.csp involving the openvpn_cli handler or unusual file_id values. Look for command-injection indicators such as shell metacharacters, encoded separators, command substitution, unexpected whitespace, or values that do not match the device’s normal file identifier format. Because the router may have limited logging, upstream telemetry is particularly important.

Technical Notes: Detection Query

A generic search in a web or firewall log source might look like this:

uri_path="/protocol.csp"
AND (
  "openvpn_cli" OR
  "file_id"
)
AND (
  "%3b" OR "%7c" OR "%26" OR "%24%28" OR
  ";" OR "|" OR "&&" OR "$(" OR "`"
)

This is a triage pattern, not a validated exploit signature. URL encoding, alternate encodings, HTTP method differences, and device-specific logging formats can produce false negatives or false positives. Tune it against normal OpenVPN administrative traffic and correlate hits with source IP, response status, request volume, and subsequent configuration changes.

For a SIEM using a normalized query language, an example detection could be:

event.category:web
and url.path:"/protocol.csp"
and (http.request.body:*file_id* or url.query:*file_id*)
and (
  http.request.body:*%3b* or
  http.request.body:*%7c* or
  http.request.body:*%26* or
  http.request.body:*%24%28* or
  http.request.body:*%60*
)

Search for post-access indicators as well:

  • Unexpected DNS servers
  • Changed administrator accounts
  • New port-forwarding rules
  • Altered VPN settings
  • Unexplained firmware or configuration changes
  • Outbound connections from the router to unfamiliar hosts
  • Sudden traffic from the router toward internal management services

Confirm whether the device can provide command-history, process, or persistence telemetry; many embedded routers cannot.

Incident Response Priorities

If you identify suspicious requests or configuration changes:

  1. Isolate the router from the internet and unnecessary internal networks.
  2. Preserve firewall, proxy, router, and network-flow logs.
  3. Document the device model, firmware version, configuration state, and exposure history.
  4. Reset administrative credentials from a trusted system.
  5. Review DNS, VPN, port-forwarding, and administrator settings for unauthorized changes.
  6. Reflash only with firmware obtained through an official WAVLINK channel.
  7. Replace the device if a trusted fixed version cannot be confirmed.
  8. Investigate adjacent systems for credential theft or lateral movement.

Do not assume that a factory reset proves the device is clean. Embedded-device persistence and log limitations may prevent complete verification.

References and Further Reading

The primary technical reference identified in the supplied CVE data is the GitHub write-up describing the WN536AX6-A file_id issue:

The authoritative record should be consulted for updates to the description, severity, affected versions, and references:

Additional third-party vulnerability records are available from VulDB:

As of the reviewed data, no confirmed fixed firmware version or official WAVLINK security advisory was supplied. Track WAVLINK’s official support and firmware channels, validate any candidate release against the affected device model, and retain evidence of the version deployed.

The most important unresolved items are:

  • The complete affected firmware range
  • The fixed firmware version
  • The authentication requirement
  • The exact exploit syntax
  • Confirmation of real-world exploitation

Treat WAVLINK WN536AX6-A V260507 as critically exposed until a vendor-confirmed secure state is established. First restrict its network reachability and check for exploitation attempts; then remediate or replace devices that cannot be verified as fixed.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.

Choosing a tool? Pricing and head-to-head guides

Last verified: 2026-11-02

Disclaimer: This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.