CVE-2026-8697: Login Rate Limit Bypass on TP-Link Archer C64

CVE-2026-8697 is a logic flaw in the TP-Link Archer C64's OS (called TPOS in the debug message). It lets any unprivileged user connected to the router to bypass the web UI rate limit by using a residual SSH service. A simple Python script can be used to try out many passwords in a short amount of time and obtain full admin access on the router.

POC: poc.py

The router has a debug SSH service which does not grant a shell to the router, rather it just exits when the correct password has been entered. But it uses the same password as the admin interface and has neither rate limits nor lockout policies. As such, it can be used as a high-speed authentication oracle to brute-force the password. This vulnerability can be used by malicious or compromised IoT devices on the network to gain full admin access to the router. An attacker cannot gain shell access through this interface, but they can easily verify credentials to compromise the primary web management interface.

This vulnerability has been patched in firmware version 1.15.0, which simply removes the service. To test your router, use this command (Linux/macOS):

timeout 10 nc -vz 192.168.0.1 22
echo $?

Replace the IP address with the address you use to connect to the router's web interface. If the output is 0 or it shows succeeded! then your router is vulnerable. Otherwise, it is not. In Windows, run the following in PowerShell:

tnc 192.168.0.1 -Port 22

If it shows TcpTestSucceeded : True then your router is vulnerable. Otherwise if it hangs indefinitely or shows it as False then it is not vulnerable.

The bug is entirely logic-based and does not require memory corruption, ASLR bypass or winning race conditions.

Discovery and Reproduction

At the time, I was learning Nmap and for fun decided to scan my router. At that time I was not looking for vulnerabilities but I noticed an open SSH service.

$ sudo nmap -A -T4 192.168.0.1
Starting Nmap 7.99 ( https://nmap.org ) at 2026-04-22 20:06 +0600
Nmap scan report for 192.168.0.1
Host is up (0.0028s latency).
Not shown: 996 filtered tcp ports (no-response)
PORT    STATE SERVICE    VERSION
22/tcp  open  ssh        OpenSSH 6.6.0 (protocol 2.0)
| ssh-hostkey: 
|_  1024 c3:db:85:33:94:d5:f7:c9:91:18:a0:73:5c:1a:aa:a5 (DSA)
53/tcp  open  tcpwrapped
80/tcp  open  http       TP-LINK router http config
|_http-title: Opening...
443/tcp open  ssl/https?
| ssl-cert: Subject: commonName=tplinkwifi.net/countryName=CN
| Subject Alternative Name: DNS:tplinkwifi.net, IP Address:192.168.0.1
| Not valid before: 2010-01-01T00:00:00
|_Not valid after:  2030-12-31T00:00:00
|_ssl-date: TLS randomness does not represent time
MAC Address: 78:8C:B5:25:3B:AF (TP-Link Systems)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Aggressive OS guesses: Canon imageRUNNER C5185 printer or Mercusys AC12G WAP (96%), Canon imageRUNNER C2380 or C2880i or Xerox Phaser 8860MFP printer (92%), Fujitsu Externus DX80 or IBM DCS9900 NAS device (92%), VxWorks (92%), Avaya 4526GTX switch (92%), Nortel CS1000M VoIP PBX or Xerox Phaser 8560DT printer (88%), Aastra Dialog 4425 IP phone (87%), HP ProCurve 3500yl, 5406zl, or 6200yl switch or UTStarcom F1000 VoIP phone (87%), Apple AirPort Express WAP or AMX NI-3100 controller (VxWorks) (86%), Xerox ApeosPort-IV C3370 printer (86%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 1 hop

The log above shows an SSH service running OpenSSH 6.6.0 (a legacy version from 2014, but the version does not matter for this). Seeing the very old version, I suspected that it could be used by an attacker and tried to SSH into it with the intention of getting a shell and updating the firmware. At that point I was trying to secure my router, not to find vulnerabilities. However, connecting to it presented an interesting problem: the host key and public key algorithms were not supported on my version of OpenSSH. Using -o also did not work in my system, so I had to use a debian:bullseye-slim container which has an OpenSSH client supporting the diffie-hellman-group14-sha1 and ssh-dss algorithms.

Inside the container, after installing the OpenSSH client, I was able to connect to the SSH server.

ssh -o KexAlgorithms=+diffie-hellman-group1-sha1 \
    -o HostKeyAlgorithms=+ssh-dss [email protected]

I used this and was finally able to connect to the SSH server, which greeted me with the message TPOS 5 IPSSH Test and a password prompt. However, after entering the password, the connection just closed immediately. I even tried directly running a command but it did not run the command. I realized that there was no shell, so an attacker could not get access to my router. So my router is safe, right? Well, not really. I realized that even though you did not get any access, you did get to know if your password was correct or not. And that password was the same as the web interface password, and there were absolutely no rate limits or anything to stop a brute-force attack. That is when the idea of turning this into a CVE came to me. I tried to automate the attack. First I tried using sshpass in a bash loop but you could not use multiple passwords per connection, so I tried making a Python script. That is the attached POC.

To use the POC, first create a venv and install pexpect. Note that the script does not use Pexpect's pxssh module since it does not support trying multiple passwords in a single connection.

python3 -m venv venv
source venv/bin/activate
pip install pexpect

Save the script to poc.py and run it. You can optionally pass in a path to a newline-separated password list as the first argument. If you don't, it will use the numbers from 1 to 100 as passwords (for speed testing).

python3 poc.py list.txt

You can parallelize the attack by running multiple instances with different lists. If you run more than 3 instances, you will start to see connection errors. The script still makes sure all the passwords are tried.

python3 poc.py list1.txt &
python3 poc.py list2.txt &
python3 poc.py list3.txt &

Potential Impact

An attacker can use a malicious or compromised IoT device on the network to brute-force the password and gain admin access to the admin interface. There is no indication to the user that this is happening, and the attacker can do this for a long time without being detected. Once the attacker has access to the admin interface, they can change the DNS settings to perform DNS hijacking, change the Wi-Fi password to lock out users, use static routing to intercept unencrypted traffic or block network access by routing to a nonexistent IP, forward ports, turn off the firewall/ALG and more.

CVSS 4.0

The CVSS 4.0 attack vector for this vulnerability is:

CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:H

, which resolves to a score of 9.3 Critical. My reasoning for each metric is as follows: