CVE-2026-15701: TOTOLINK NR1800X Remote Stack Buffer Overflow
TL;DR - CVE-2026-15701 is a critical 9.8 remote stack-based buffer overflow in TOTOLINK NR1800X firmware 9.1.0u.6279_B20210910. - Public exploit availability is stated by NVD; active in-the-wild exploitation is not confirmed by CISA KEV. - If you run this firmware, restrict management access immediately and check for updated vendor firmware.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-15701 |
| CVSS score | 9.8 (Critical) |
| Attack vector | Remote/network reachable |
| Auth required | Unknown from available source material; defenders should assume unauthenticated exposure is high risk until proven otherwise |
| Patch available | Not verified as of 2026-07-14 |
This vulnerability affects the TOTOLINK NR1800X router and has been described by NVD as a remotely exploitable stack-based buffer overflow. The vulnerable code path is the Form_Logout function associated with /formLogout.htm in the lighttpd component, with the Host argument identified as the trigger input.
The most important operational point is that the NVD description explicitly says a public exploit has been made available. Even without confirmed CISA KEV listing, that combination, critical score plus public exploit, should move this issue toward immediate triage for any organization with exposed or remotely administered devices.
What Is This Vulnerability?
CVE-2026-15701 is a stack-based buffer overflow in the TOTOLINK NR1800X web management path. According to the available NVD description, the flaw exists in the Form_Logout function of /formLogout.htm within the lighttpd component. The vulnerable condition is triggered by manipulation of the Host argument.
In practical terms, a buffer overflow in a router’s web interface is dangerous because management services often run with high privileges and sit at the edge of the network. If input copied from an HTTP header or related request field is not properly bounds-checked before being written into a stack buffer, an attacker may be able to crash the service or potentially gain code execution on the device. The available source material confirms the weakness class and remote reachability, but it does not provide enough verified detail to safely claim exact exploit mechanics beyond that.
A key nuance here is the mention of the Host argument. In HTTP handling, Host is commonly supplied by the client and often trusted more than it should be in embedded web stacks. If the logout handler or downstream request processing copies Host into a fixed-size stack variable without validating length, a crafted request could overflow memory during request processing.
Because the public data retrieved for this article does not include a patch diff, vendor advisory text, or source code excerpt, defenders should avoid assumptions about the exact overwrite path, return address control, or exploit reliability. What is verified is enough to treat this as a serious remote compromise risk.
Technical Notes
A simplified example of the kind of dangerous pattern defenders should expect in embedded HTTP handlers looks like this:
void Form_Logout(request_t *req) {
char host_buf[64];
strcpy(host_buf, req->host); // unsafe if host is attacker-controlled
// logout handling continues
}
A malicious request path could resemble this at a high level:
POST /formLogout.htm HTTP/1.1
Host: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Content-Length: 0
The example above is illustrative only. It is not a confirmed exploit string for this CVE, but it matches the verified root cause category: unsafe handling of attacker-controlled Host input leading to stack overflow.
Who Is Affected?
The specifically confirmed affected product and version are:
- TOTOLINK NR1800X
- Firmware version:
9.1.0u.6279_B20210910
At the time of writing, that is the only version explicitly verified from the available primary-source material used here. The research note did not confirm a broader vulnerable range, and no retrievable official vendor advisory was available in the provided evidence to establish whether earlier or later firmware builds are also affected.
That matters for defenders because embedded device CVEs are often published before vendors provide clean version matrices. If you operate the NR1800X and cannot quickly verify firmware provenance, assume devices running 9.1.0u.6279_B20210910 are affected, and treat adjacent builds with caution until TOTOLINK publishes remediation guidance or a fixed firmware release note naming this CVE.
For managed service providers and SMB administrators, the exposure question is straightforward: if the router’s administrative web interface is internet-accessible, remotely reachable over VPN, or exposed to untrusted internal segments, the risk is materially higher. Edge routers frequently face opportunistic scanning, and public exploit availability tends to shorten the time between disclosure and real-world attack attempts.
Technical Notes
Useful inventory checks include confirming device model and firmware version from administrative export, screenshots, or web interface details. If shell access or backup configuration metadata is available, preserve that evidence before making changes.
Example asset tracking entry:
Vendor: TOTOLINK
Model: NR1800X
Firmware: 9.1.0u.6279_B20210910
Mgmt interface exposed to internet: Yes/No
Remote admin enabled: Yes/No
CVSS Score Breakdown
The verified base score is 9.8, which places CVE-2026-15701 in the Critical category. The tool-returned NVD record used for this article did not include the exact CVSS vector string, so it would be inaccurate to claim the precise component values from that source alone.
Even without the vector string, a 9.8 score usually implies a highly dangerous combination such as remote exploitability, low attack complexity, and severe impact to confidentiality, integrity, and availability. Since this is a stack-based buffer overflow in a router management component and is described as remotely exploitable, that severity is consistent with a potential device-compromise scenario.
Defenders should be careful not to over-read what is missing. We cannot safely state the official values for privileges required, user interaction, or scope from the evidence provided here. In the absence of a published vector string, the operational assumption should be conservative: treat the issue as remotely reachable and high impact, especially if the management service is exposed beyond a tightly controlled admin network.
For risk ranking, this CVE belongs near the top of appliance patch queues because the affected asset class, internet-facing routers, often acts as both a perimeter device and a trusted control plane component.
Exploitation Status
The strongest verified statement on exploitation status comes from NVD, which says that the exploit has been made available to the public and could be used for attacks. That means defenders should consider public proof-of-concept or exploit discussion to exist, even if the exact PoC content was not extractable from the referenced GitHub page during source retrieval.
What is not confirmed is active in-the-wild exploitation. The CISA KEV lookup result for this CVE is false, meaning the vulnerability is not listed in the Known Exploited Vulnerabilities catalog at the time of writing. That does not prove nobody is exploiting it; it only means there is no KEV-backed confirmation available from that dataset.
So the clean defender summary is:
- Public PoC / exploit available: Yes, per NVD description
- Active exploitation in the wild confirmed: No verified confirmation from CISA KEV
- CISA KEV listed: No, as of 2026-07-14
Organizations should treat this as a likely target for scanning and opportunistic abuse, especially because router flaws with public exploit references are frequently incorporated into botnet tooling and internet-wide exploitation workflows.
Technical Notes
Track external scanning and exploit attempts against the management interface with special attention to requests targeting the logout endpoint:
/formLogout.htm
If you operate passive DNS, reverse proxy, or firewall telemetry, look for spikes in management-plane probing from untrusted IP space shortly after disclosure.
How to Detect It
Detection is challenging on consumer and SMB routers because logging is often limited. Still, defenders can look for anomalous requests to /formLogout.htm, especially requests carrying abnormally long or malformed Host headers. If the device exposes access logs through lighttpd or a centralized syslog integration, those records are the first place to look.
The second detection angle is behavioral. Stack-based overflows on embedded devices commonly produce unstable web management behavior, crashes, watchdog restarts, or unexplained reboots. If you see repeated management daemon failures, login page instability, or router restarts that correlate with external request bursts, investigate this CVE as a possible cause.
If detailed router logs are unavailable, inspect upstream network controls such as firewalls, reverse proxies, or SPAN captures for suspicious requests aimed at /formLogout.htm. A management request with an oversized Host field is a useful detection heuristic even if it does not prove successful exploitation.
Technical Notes
Example HTTP access log pattern to search for:
POST /formLogout.htm HTTP/1.1
GET /formLogout.htm HTTP/1.1
Example grep for exported logs:
grep -E '(/formLogout\.htm|Host:)' router-http.log
Example Sigma-style idea for translated web logs:
title: Suspicious TOTOLINK NR1800X formLogout Host Header Abuse
logsource:
category: webserver
detection:
selection_path:
cs-uri-stem: "/formLogout.htm"
selection_host_length:
request_headers|contains: "Host:"
condition: selection_path and selection_host_length
level: high
Example Suricata-style detection concept for unusually long Host values sent to the logout path:
alert http any any -> $HOME_NET any (
msg:"Possible CVE-2026-15701 exploitation attempt";
flow:to_server,established;
http.uri; content:"/formLogout.htm";
http.header; content:"Host|3a 20|"; nocase;
pcre:"/Host\x3a\x20.{80,}\r\n/Hi";
sid:42015701; rev:1;
)
The exact threshold should be tuned to your environment. The goal is to catch abnormally long hostnames in requests to this specific path.
Mitigation and Patching
The currently verified mitigation reality is incomplete: a fixed firmware version has not been verified from the available source material. That means you should not guess a safe target release based on naming patterns alone. Instead, monitor TOTOLINK’s official firmware distribution and release notes for the NR1800X and look for a version explicitly described as fixing CVE-2026-15701 or the Form_Logout buffer overflow.
Until a verified fixed version is available, the best mitigations are exposure reduction and administrative hardening. Disable remote administration if enabled. Restrict access to the router web interface to a dedicated management VLAN or a small set of trusted IP addresses. If the device is directly internet-accessible for administration, move that access behind VPN or disable it entirely. For higher-risk environments, especially where the device is exposed and cannot be promptly updated, replacement should be considered.
If you later identify a vendor-provided patched firmware, document both the vulnerable version and the fixed target in change records. Because this is a network edge device, schedule the maintenance window carefully and verify configuration backup and rollback options before flashing new firmware.
Technical Notes
If you have shell or management access to surrounding infrastructure, implement immediate network restrictions. Example firewall policy approach:
# Example only: restrict router admin interface to one trusted admin IP
iptables -A INPUT -p tcp --dport 80 ! -s 198.51.100.10 -j DROP
iptables -A INPUT -p tcp --dport 443 ! -s 198.51.100.10 -j DROP
If administration is configured through the router UI, disable remote management and UPnP where possible, then verify from an external network that the interface is no longer reachable.
For firmware operations, use the vendor’s documented upgrade path once a fixed build is published. A generic workflow might look like:
1. Download the latest NR1800X firmware only from the official TOTOLINK site.
2. Verify the model exactly matches NR1800X.
3. Back up the current configuration.
4. Upload firmware through the administrative interface.
5. Reboot and confirm the running firmware version.
6. Re-test external exposure and administrative settings.
Because no verified fixed version number is available in the source material, do not record a guessed upgrade target in your patch plan. If you cannot confirm remediation status, treat the workaround posture, access restrictions, segmentation, and exposure removal, as the primary control.
References
Primary reference material confirms the product, affected version, root cause category, and exploit-availability statement, but not a fixed firmware version. That gap is important and should be called out in internal advisories so teams know patch verification is still pending.
Use the following references to track updates, verify remediation details, and monitor for further exploitation reporting:
- NVD CVE record for CVE-2026-15701
- CISA Known Exploited Vulnerabilities catalog lookup for CVE-2026-15701
- GitHub issue referenced by NVD:
https://github.com/fu9-dotom/cve/issues/1 - VulDB CVE page:
https://vuldb.com/cve/CVE-2026-15701 - TOTOLINK firmware download page for NR1800X:
https://www.totolink.net/home/menu/detail/menu_listtpl/download/id/225/ids/36.html - ENISA EUVD entry:
https://euvd.enisa.europa.eu/enisa/EUVD-2026-4146 - GitHub advisory result surfaced in research:
https://github.com/advisories/GHSA-c7c4-v9c9-65gw
When communicating this issue internally, be explicit about what is confirmed versus unknown:
- Confirmed:
TOTOLINK NR1800X, firmware9.1.0u.6279_B20210910, remote stack-based buffer overflow,Form_Logout,/formLogout.htm,Hostargument, CVSS 9.8, public exploit availability stated by NVD. - Unknown / not verified: exact CVSS vector string, broader affected version range, official fixed version number, and confirmed in-the-wild exploitation outside public exploit availability.
That distinction helps defenders act quickly without overstating what the current evidence supports.
For further information on malware threats and router security, check our articles on what is malware and how to secure your AWS account.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.