CVE-2026-105484: TOTOLINK X6000R Flaw
CVE-2026-105484 is a critical remote OS command-injection vulnerability affecting the TOTOLINK X6000R router. The explicitly affected firmware is 9.4.0cu.652_B20230116, and NVD assigns the issue a CVSS base score of 10.0.
TL;DR - CVE-2026-105484 affects the TOTOLINK X6000R firmware-upload handler. - The explicitly affected firmware is
9.4.0cu.652_B20230116. - No public proof of concept or CISA KEV listing is confirmed. - Disable WAN administration, restrict management access, and upgrade after verifying firmware compatibility. - No CVE-specific fixed firmware version has been confirmed.
Summary
CVE-2026-105484 affects the TOTOLINK X6000R router’s UploadFirmwareFile Handler. The vulnerable logic is the firmware_check function in /cgi-bin/cstecgi.cgi, where attacker-controlled input in the file_name argument can result in operating-system command injection.
Analyst’s Take: Remove affected X6000R devices from direct Internet exposure first. The vulnerability is in the firmware-upload path, and no confirmed fixed version is identified in the available advisory material. Treat later firmware as a mitigation candidate until TOTOLINK maps a release to this CVE or technical review confirms that the vulnerable code has been removed.
| Field | Assessment |
|---|---|
| CVE ID | CVE-2026-105484 |
| CVSS score | 10.0 |
| Attack vector | Remote |
| Authentication required | Unknown from available records |
| Privileges required | Unknown from available records |
| Affected product | TOTOLINK X6000R |
| Explicitly affected firmware | 9.4.0cu.652_B20230116 |
| Confirmed fixed version | None identified |
| CISA KEV status | Not listed |
TOTOLINK publishes later X6000R firmware, including V9.4.0cu.1498_B20250826. However, the available download page does not explicitly state that this release fixes CVE-2026-105484. Administrators should therefore treat newer firmware as a mitigation candidate rather than a confirmed fix.
Root Cause
The root cause is improper handling of the file_name argument in the X6000R firmware-validation path. The firmware_check function processes this value in a way that allows operating-system command content to reach a command-execution context.
Input intended to identify or validate a firmware file is not sufficiently isolated from shell or operating-system command processing. The available vulnerability record does not disclose the exact vulnerable statement, command delimiter, HTTP method, request format, or exploit payload.
The record also does not establish whether exploitation requires an authenticated firmware-upload session. Defenders should avoid assumptions about authentication or input encoding and protect the entire administrative interface from untrusted networks.
A successful exploit could allow an attacker to execute commands with the privileges of the affected router service. The precise privilege level and persistence options are not documented in the available sources. Router compromise could expose configuration data, redirect traffic, alter DNS settings, modify firewall rules, or provide a foothold into connected networks. These outcomes should be validated during incident response rather than treated as confirmed behavior for this CVE.
Organizations reviewing firmware trust controls may also benefit from this code-signing glossary guide, particularly when validating firmware provenance and update workflows.
Who’s Exposed
The explicitly affected product and version are:
- TOTOLINK X6000R
- Firmware
9.4.0cu.652_B20230116 - TOTOLINK’s equivalent display format:
V9.4.0cu.652_B20230116
This is the only affected version directly identified in the available NVD record. A complete affected-version range has not been published in the supplied material. Organizations should not conclude that every release before or after this version is vulnerable, and they should not assume that a later release is fixed solely because it has a higher version number.
TOTOLINK’s download page lists these X6000R releases:
| Firmware release | Status for this CVE |
|---|---|
V9.4.0cu.652_B20230116 |
Explicitly identified as affected |
V9.4.0cu.852_B20230719 |
CVE status not confirmed |
V9.4.0cu.1360_B20241207 |
CVE status not confirmed |
V9.4.0cu.1454_B20250619 |
CVE status not confirmed |
V9.4.0cu.1458_B20250708 |
CVE status not confirmed |
V9.4.0cu.1498_B20250826 |
Newest listed release in the supplied research; not confirmed as the fix |
The highest-risk deployments are X6000R devices whose web-management interface is reachable from the Internet or broad, untrusted network segments. The available research does not confirm that WAN access is required for exploitation, nor does it confirm whether authentication is required.
As a precaution, treat affected devices as exposed if their administration interface is reachable outside a tightly controlled management network.
Severity Breakdown
NVD assigns CVE-2026-105484 a CVSS base score of 10.0, the maximum severity rating. The score reflects the reported remote nature of the vulnerability and the potential for OS command execution.
A command-injection flaw in an edge router is operationally serious because the device commonly sits at a network boundary and may control routing, DNS, firewall policy, or administrative access.
The complete CVSS vector was not supplied in the available NVD record. The following component values therefore cannot be stated reliably:
| CVSS component | Available assessment |
|---|---|
| Attack vector | Remote |
| Attack complexity | Not supplied |
| Privileges required | Not supplied |
| User interaction | Not supplied |
| Scope | Not supplied |
| Confidentiality impact | Not supplied |
| Integrity impact | Not supplied |
| Availability impact | Not supplied |
| Base score | 10.0 |
The missing vector matters for prioritization. Teams should not infer that the issue is unauthenticated, Internet-wide, or exploitable without user interaction merely from the 10.0 score.
Until the vendor or NVD provides the vector and authentication requirements, restrict access as though an exposed management service could be targeted remotely.
Exploitation Status
CVE-2026-105484 is not currently listed in the CISA Known Exploited Vulnerabilities catalog. No CISA due date, required federal remediation action, ransomware-campaign flag, or date-added entry exists for this CVE in the supplied assessment.
No CVE-specific public proof-of-concept repository was identified in the research. Search results containing unrelated 2026 CVEs should not be treated as evidence of a working exploit for this issue.
Current status:
- Public PoC: Not confirmed.
- Active exploitation: Not confirmed.
- CISA KEV listing: No.
- Technical exploitability: High, because the issue is described as remote OS command injection.
Absence from KEV or GitHub does not demonstrate that exploitation has not occurred. Consumer routers are frequently scanned opportunistically, and vulnerable management interfaces may be targeted without a public exploit being published.
Internet-facing X6000R devices should be handled as high-priority exposure even without confirmed exploitation.
Sources
The primary technical record is the NVD entry for CVE-2026-105484:
- NVD API record: https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-105484
- NVD-listed vulnerability reference: https://vuldb.com/vuln/413619
- NVD-listed CTI reference: https://vuldb.com/vuln/413619/cti
- NVD-listed submission reference: https://vuldb.com/submit/984434
The official product and firmware resources are:
- TOTOLINK X6000R firmware page: https://www.totolink.net/home/menu/detail/menu_listtpl/download/id/247/ids/36.html
- TOTOLINK X6000R product page: https://www.totolink.net/products/x6000r
- TOTOLINK security bulletins: https://www.totolink.net/support/security-bulletins
The supplied research also references Palo Alto Networks Unit 42 reporting on TOTOLINK X6000R vulnerabilities:
That reporting indicates that updated X6000R firmware exists for vulnerabilities affecting the product, but the available material does not establish that a specific release fixes CVE-2026-105484. The VulDB references returned access-denied responses during retrieval, so their advisory content was not independently verified.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.
Detection Guidance
Begin by building an inventory of X6000R devices and recording:
- Firmware versions
- Hardware revisions
- Management-interface bindings
- WAN administration status
- Administrative access paths
- Recent configuration changes
Prioritize devices running 9.4.0cu.652_B20230116, especially those with WAN administration enabled or port-forwarded access to the router interface.
Review web-server, system, firewall, DNS, and configuration-change logs for:
- Unexpected requests to
/cgi-bin/cstecgi.cgi - References to
firmware_check - Unusual values associated with
file_name - Requests originating from the WAN
- Activity outside approved maintenance windows
- Unexpected methods or content types
- Configuration changes followed by outbound connections
The available research does not provide a definitive exploit payload or vendor-specific log format. These indicators are therefore triage signals rather than a complete detection signature.
Technical Notes
A network sensor or reverse proxy can begin with a narrow request-pattern query:
http.request.uri contains "/cgi-bin/cstecgi.cgi"
and (
http.request.body contains "firmware_check"
or http.request.body contains "file_name"
)
For environments using Zeek logs, a preliminary search could be:
grep -E '(/cgi-bin/cstecgi\.cgi|firmware_check|file_name)' http.log
Investigate unexplained DNS-server changes, new administrator accounts, altered firewall rules, firmware-version changes, and connections from the router to unfamiliar external addresses.
Because the exact request structure is not documented, the absence of these strings is not evidence that a device was not attacked.
Remediation Steps
1. Remove affected devices from Internet exposure
Identify every X6000R running 9.4.0cu.652_B20230116 and remove it from direct Internet exposure.
Disable WAN or remote administration unless it is strictly required. Permit administrative access only from a dedicated management VLAN, VPN, or explicitly allowlisted administrator addresses. Do not expose the firmware-upload interface through port forwarding or reverse proxies.
For broader home and small-office IoT security guidance, see how to secure IoT devices on your network.
2. Verify and apply compatible firmware
TOTOLINK lists V9.4.0cu.1498_B20250826 as a later X6000R release, but no CVE-specific fixed version is confirmed in the available advisory material.
There is therefore no confirmed fixed version number to state for CVE-2026-105484. Upgrade to the latest firmware appropriate for the exact hardware revision after verifying the vendor’s release notes and compatibility.
TOTOLINK warns that selecting the wrong hardware version can damage the device.
3. Restrict management traffic
The vendor-provided material does not document a supported command-line firmware-upgrade procedure. Use the router’s documented administration workflow or vendor-supported update mechanism, and verify the resulting firmware version afterward.
As an immediate network workaround, restrict the management service at the perimeter. For example, a Linux gateway using nftables can allow management only from a trusted administration network:
sudo nft add rule inet filter input iifname "wan0" tcp dport { 80, 443 } drop
sudo nft add rule inet filter input iifname "mgmt0" ip saddr 192.0.2.0/24 tcp dport { 80, 443 } accept
Adapt interface names, ports, and the management subnet to the deployment.
This workaround does not repair the vulnerable firmware. It reduces exposure while a confirmed remediation is obtained.
4. Rotate credentials and review the device
After upgrading:
- Change router administrator credentials.
- Use a unique, strong password; a password manager such as Try 1Password → can help administrators generate and store unique credentials.
- Review DNS, firewall, port-forwarding, and administrator-account settings.
- Export logs if the device supports it.
- Check connected systems for suspicious activity.
- Consider factory-resetting and rebuilding the device if compromise indicators are present.
Do not upload a firmware image intended for a different hardware revision.