CVE-2026-13539: Wavlink WL-NU516U1-A Guest_ssid Buffer Overflow
| Field | Value |
|---|---|
| CVE ID | CVE-2026-13539 |
| CVSS v3.1 | 8.8 |
| Attack vector | Network |
| Auth required | Low privileges required |
| Patch status | Patch available |
TL;DR - Remote stack-based buffer overflow in Wavlink WL-NU516U1-A
wireless.cgi. - Confirmed affected firmware isM16U1_V240425; patch artifact is available. - Public exploit code exists, but CISA KEV does not confirm in-the-wild exploitation.
Vulnerability at a Glance
CVE-2026-13539 is a high-severity stack-based buffer overflow in the Wavlink WL-NU516U1-A router platform. The vulnerable code is reported in the sub_407504 function within /cgi-bin/wireless.cgi, specifically in handling the Guest_ssid POST parameter. NVD describes the issue as remotely exploitable and states that public exploit code is available.
The official CVSS v3.1 base score is 8.8 with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. In practical terms, that means exploitation is possible over the network, requires only low privileges, does not require user interaction, and can have high impact on confidentiality, integrity, and availability. For defenders, the detail that matters most is that this is not just a denial-of-service edge case. A stack overflow in a device CGI handler can translate into service crashes, unstable device behavior, or potentially code execution depending on exploit reliability and device hardening.
What is This Vulnerability?
At a technical level, the flaw is a classic bounds-handling failure in a web-facing firmware component. The vulnerable component is /cgi-bin/wireless.cgi, and the attacker-controlled field is the Guest_ssid parameter sent in an HTTP POST request. NVD attributes the bug to the sub_407504 function and classifies it as a stack-based buffer overflow.
What we can say with confidence is limited to what the primary sources state. The confirmed facts are: the product is Wavlink WL-NU516U1-A, the affected firmware explicitly named is M16U1_V240425, the vulnerable file is /cgi-bin/wireless.cgi, and the trigger input is Guest_ssid. What we should not do is speculate about the exact unsafe C routine, stack layout, or exploit chain beyond that. In the absence of a vendor diff or source disclosure, defenders should assume the CGI handler does not safely enforce the expected maximum length for Guest_ssid.
Who is Affected?
The only confirmed affected version in the available source material is Wavlink WL-NU516U1-A firmware M16U1_V240425. That exact firmware version is named in the NVD description. At this time, there is no confirmed broader version range in the provided evidence, so it would be inaccurate to claim that all earlier firmware builds are vulnerable.
That matters operationally because many vulnerability articles overstate firmware ranges. Here, the correct statement is narrow: confirmed affected version: M16U1_V240425. If you operate WL-NU516U1-A devices and cannot immediately verify firmware inventory, the prudent assumption is that any device still running M16U1_V240425 is exposed. If you run a different build and do not yet have vendor release notes proving unaffected status, treat it as potentially affected until verified. That conservative stance is appropriate because embedded device versioning is often inconsistent across UI pages, file names, and support portals.
Exploitation Status
Public exploit availability is the strongest urgency signal here. NVD explicitly states that the exploit is publicly available and might be used, and the CVE record references a GitHub repository associated with the vulnerability. That means defenders should assume exploit details are accessible to researchers, red teams, and opportunistic attackers.
By contrast, confirmed exploitation in the wild is not established from the provided evidence. The CVE is not listed in CISA’s Known Exploited Vulnerabilities catalog at the time of lookup, so there is no CISA-backed confirmation of active exploitation. That does not mean no one is exploiting it. It means defenders currently lack authoritative public evidence of in-the-wild activity from that source. The correct operational posture is: PoC exists, exploitation is plausible, active abuse is unconfirmed. For SMBs and MSPs, that combination usually justifies accelerated patching because internet-exposed administrative CGI surfaces are commonly scanned once exploit material is public.
Risk Assessment for Defenders
This vulnerability deserves priority because it combines four factors that often lead to rapid weaponization: remote reachability, low attack complexity, high impact, and public exploit availability. The main limiting factor is the requirement for low privileges. In real networks, that still leaves several plausible paths: weak admin passwords, password reuse, exposed management interfaces, or compromise of an internal user with access to the device.
For SMBs, branch offices, and MSP-managed environments, the business risk is larger than the CVSS number alone suggests. Edge devices often sit outside normal EDR coverage, have weak logging, and are overlooked in patch cycles. A successful exploit against the management plane of a router can affect not only the device itself but also downstream traffic visibility, policy enforcement, and trust in the network edge. If you have this model in production and are on M16U1_V240425, treat patching as near-term work rather than waiting for KEV inclusion.
Bottom Line
CVE-2026-13539 is a remote stack-based buffer overflow in Wavlink WL-NU516U1-A affecting the confirmed firmware version M16U1_V240425. A vendor fix exists, and a public PoC is referenced by NVD. In-the-wild exploitation is not confirmed by CISA KEV at the time of writing, but defenders should not take that as a reason to wait. If you operate this model, identify devices on M16U1_V240425, restrict management exposure, and move to the fixed firmware artifact as soon as your maintenance process allows.
For further information on security measures, you can check our articles on What is Data Classification and How to Prioritize Critical Vulnerabilities: A Practical Triage Framework.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Fixed Version and Patch Status
A vendor fix is available, but the publicly retrievable material does not clearly provide a human-readable fixed version string. Instead, the evidence points to a patched firmware artifact hosted by the vendor:
- Known affected version:
M16U1_V240425 - Known fixed artifact:
WINSTAR_NU516U1-WO-A-2026-06-22-5ccde97-mt7628-squashfs-sysupgrade.bin
That distinction is important. You can safely say a patch exists because the NVD text explicitly says the vendor released a fixed version and references the firmware binary. You should not claim a clean fixed version label if you do not have one from a vendor advisory or release note. For change control, teams should record the actual firmware filename as the current fixed reference and retain a local checksum after download. If your process requires a formal version string for CMDB or compliance evidence, note that the fixed artifact is known, but the fixed version name is not clearly published in the retrieved source material.
Detection and Hunting Guidance
Detection for this issue should focus on HTTP POST activity to /cgi-bin/wireless.cgi, especially requests containing the Guest_ssid parameter with unusually long values. Even if full payload logging is unavailable, spikes in requests to that endpoint, followed by web process crashes, router instability, or service restarts, are worth investigating.
You should also look for signs of administrative access preceding the suspicious request. Because the CVSS vector includes PR:L, exploitation requires low privileges rather than being fully unauthenticated. That means the path to compromise may start with default credentials, credential stuffing against the router admin interface, password reuse, or previously obtained admin access. If your telemetry is limited, pair HTTP request review with device management logs and network perimeter logs to reconstruct whether a valid session existed before the suspicious POST.
Technical Notes
A simple log pattern to hunt for is any HTTP POST to the vulnerable CGI path with Guest_ssid= present:
POST /cgi-bin/wireless.cgi HTTP/1.1
Content-Type: application/x-www-form-urlencoded
...
Guest_ssid=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Example grep-style triage if you have exported web or reverse-proxy logs:
grep -Ei 'POST .*\/cgi-bin\/wireless\.cgi|Guest_ssid=' /var/log/* 2>/dev/null
Example Suricata rule for noisy but practical detection of obvious exploit attempts with oversized Guest_ssid values:
alert http $EXTERNAL_NET any -> $HOME_NET any (
msg:"Possible CVE-2026-13539 exploit attempt against wireless.cgi";
flow:to_server,established;
http.method; content:"POST";
http.uri; content:"/cgi-bin/wireless.cgi";
http.request_body; content:"Guest_ssid=";
pcre:"/Guest_ssid=[^&]{64,}/Pi";
classtype:web-application-attack;
sid:22613539;
rev:1;
)
If you use a SIEM with HTTP telemetry, a basic search query could look like:
url_path="/cgi-bin/wireless.cgi" AND http_method="POST" AND request_body CONTAINS "Guest_ssid="
In the absence of richer application logs from the device itself, defenders should also watch for adjacent symptoms such as sudden loss of web management access, unexplained reboots, or kernel/application crash messages collected via syslog, if enabled.
Mitigation and Patching
The primary mitigation is to upgrade affected devices away from M16U1_V240425 using the vendor-provided fixed firmware artifact. Because the fixed firmware is referenced as a downloadable binary rather than a clearly labeled version in a release note, verify carefully that the image matches your hardware variant before deployment. Back up the current configuration, stage a maintenance window, and confirm remote recovery options if the upgrade fails.
If you cannot patch immediately, reduce exposure around the management interface. Restrict administrative access to trusted management networks only, disable internet-facing router management, rotate administrative credentials, and audit for default or shared passwords. Since exploitation requires low privileges, credential hygiene and access control are meaningful compensating controls. Also consider disabling guest Wi-Fi configuration changes through less trusted operational workflows until patching is complete.
Technical Notes
If you download the fixed artifact directly for validation, use a controlled workstation and record a checksum:
curl -O "https://dl.wavlink.com/firmware/RD/WINSTAR_NU516U1-WO-A-2026-06-22-5ccde97-mt7628-squashfs-sysupgrade.bin"
sha256sum WINSTAR_NU516U1-WO-A-2026-06-22-5ccde97-mt7628-squashfs-sysupgrade.bin
A practical upgrade workflow for OpenWrt-style sysupgrade environments, if your device shell and vendor instructions support it, may resemble:
scp WINSTAR_NU516U1-WO-A-2026-06-22-5ccde97-mt7628-squashfs-sysupgrade.bin root@ROUTER_IP:/tmp/
ssh root@ROUTER_IP "sysupgrade /tmp/WINSTAR_NU516U1-WO-A-2026-06-22-5ccde97-mt7628-squashfs-sysupgrade.bin"
Do not assume the CLI path is supported on every deployed unit. Many operators will instead need to use the web administration firmware upgrade page. If immediate patching is blocked, apply a workaround by restricting access to the admin interface at the network layer. For example, place management behind an allowlist on the upstream firewall:
# Example only; implement on your actual firewall platform
iptables -A INPUT -p tcp --dport 80 -s MGMT_SUBNET -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j DROP
iptables -A INPUT -p tcp --dport 443 -s MGMT_SUBNET -j ACCEPT
iptables -A INPUT -p tcp --dport 443 -j DROP
Where possible, also disable remote web management entirely until the device is upgraded.
References
- NVD: CVE-2026-13539
- CVE.org: CVE Record
- CISA KEV Catalog: Known Exploited Vulnerabilities
- Referenced fixed firmware artifact: Download Firmware
- Referenced public PoC repository: GitHub PoC