Loading vulnerability…
Unauthenticated Telnet Enablement and Root Login in TOTOLINK X5000R cstecgi.cgi
CVE-2025-13184 is a critical authentication bypass vulnerability affecting the TOTOLINK X5000R (AX1800) router, confirmed on firmware version V9.1.0u.6369_B20230113; earlier versions sharing the same implementation may also be affected. The flaw is in the device management interface, specifically the /cgi-bin/cstecgi.cgi?action=telnet functionality, where insufficient authentication checks allow an unauthenticated attacker to enable the Telnet service with a single HTTP request. On factory-reset or default-state devices, the attacker can then connect over Telnet and log in as root with a blank password, resulting in arbitrary command execution on the router.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation results in full compromise of the router with root privileges. An attacker can execute arbitrary commands, alter device configuration, modify DNS settings, manipulate or intercept traffic traversing the device, access the filesystem and administrative functions, expose confidential network data, enroll the router into a botnet, and use the device as a foothold for lateral movement against other systems on the local network. If the management interface is reachable from the WAN or other untrusted networks, remote internet-based compromise is possible.
If you can’t patch tonight, do this now.
Do not expose the web management interface to the internet or other untrusted networks. Restrict administrative access to trusted hosts only and place the router behind a separate firewall or trusted upstream device rather than using it as the primary security boundary. Monitor for or block Telnet traffic to the device, especially unexpected TCP/23 exposure, which is a strong indicator of exploitation. Where possible, disable Telnet, ensure the device is not left in factory/default state, and configure strong non-default credentials. Treat the device as untrusted until a fixed firmware release is available.
Patch, then assume compromise.
Apply a vendor firmware update that fixes the authentication bypass once one is available. The provided content indicates that no official patch was known to be available at the time of reporting, and that a firmware update is required for complete remediation. If operationally feasible, replace the stock firmware with a supported alternative such as OpenWrt only where technically appropriate and after validating device compatibility and deployment risk. If the device cannot be adequately secured, remove it from service and replace it.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
6 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.