ZBT: due nuovi impianti di fabbrica nei router cinesi espongono l’accesso root da remoto

La scoperta: produttore identificato dal MAC e due nuovi impianti

Il 28 agosto 2026, The Hacker News ha confermato attraverso il database dei prefissi MAC registrati IEEE che i blocchi 78:A3:51 e F8:5E:3C appartengono a Shenzhen Zhibotong Electronics, l’azienda cinese che commercializza i router con il marchio Zbtlink. L’identificazione consente di risalire al produttore a partire dall’indirizzo MAC del dispositivo, un dettaglio rilevante perché molti di questi apparecchi sono venduti come white-label: lo stesso hardware e firmware finisce sotto marchi diversi, quindi il numero di modello è l’unico controllo affidabile.

La conferma arriva mentre VulnCheck ha documentato due impianti di fabbrica precedentemente sconosciuti nel firmware dei router ZBT. I componenti, chiamati SPEAKINGSTONE e DARKLANTERN, sono stati tracciati rispettivamente come CVE-2026-74232 e CVE-2026-74233. VulnCheck, in qualità di CVE Numbering Authority, ha assegnato entrambi gli identificativi. I punteggi sono elevati: 9,3 su CVSS 4.0 e 9,8 su CVSS 3.1 per entrambi, con vettori che prevedono attacco di rete, nessun privilegio richiesto e nessuna interazione dell’utente.

Nessuna advisory indica una versione firmware correttiva. I due impianti si aggiungono a ENDLESSDOORS (CVE-2026-66747), un terzo componente malevolo divulgato da VulnCheck il 5 agosto e trovato in almeno 20 modelli di router Zbtlink.

SPEAKINGSTONE: un beacon di sorveglianza con root da remoto

SPEAKINGSTONE è un servizio che esegue con il nome yunmgrd. Invia beacon in uscita su UDP/10000 verso un server di comando e controllo hardcoded: il dominio primario è www.ac-link[.]com, che il 28 agosto risolveva ancora all’indirizzo IP 47.107.224[.]89, un server Alibaba Cloud situato a Shenzhen. Il protocollo supporta tipi di messaggio che permettono a un attaccante remoto di eseguire comandi arbitrari come root, esfiltrare le credenziali PPPoE della WAN, scrivere e leggere una lista di dirottamento DNS e aprire un tunnel SSH inverso.

Poiché il traffico è in uscita, funziona da dietro NAT e da filtraggio egress ordinario, rendendo l’impianto difficile da bloccare. Esiste anche un C2 di backup hardcoded, www.findmyipaddr[.]com, che VulnCheck ha registrato perché il dominio non era registrato. Il server di backup esegue un’implementazione reverse-engineered del protocollo.

Dal momento dell’attivazione del sinkhole fino al 21 agosto, 392 dispositivi unici si sono collegati al backup. Di questi, 390 erano in Cina e l’83% risultava sulla rete China Mobile; 304 trasmettevano un SSID con prefisso CMCC e 363 si auto-dichiaravano modello L3_V2_8 con firmware 3.0.0.4.528. VulnCheck precisa che il backup viene raggiunto solo quando il C2 primario non è mai stato configurato, quindi 392 è un limite inferiore e non rappresenta il totale dei dispositivi affetti.

DARKLANTERN: command injection su porta UDP aperta a Internet

DARKLANTERN è un servizio che ascolta con il nome infosrvd su UDP/9992. Il firewall di fabbrica del router apre quella porta a connessioni in ingresso da qualsiasi indirizzo Internet, esponendo il servizio direttamente alla rete. L’autenticazione è inefficace: poggia su un salt hardcoded e su un valore MAC wildcard tutto-zero che elude il controllo dell’indirizzo.

VulnCheck descrive la falla come command injection. Un attaccante remoto non autenticato può sfruttarla per ottenere l’esecuzione di comandi come root. Tra il 18 e il 21 agosto, VulnCheck ha identificato 203 istanze DARKLANTERN internet-facing in 22 Paesi, con 16 modelli distinti auto-dichiarati. Il numero conta gli host che hanno risposto alla sonda, non i dispositivi già compromessi.

Le risposte di DARKLANTERN viaggiano su UDP/8897, ma una regola Suricata pubblicata da VulnCheck utilizza la porta 8898. La discrepanza è nota: il testo associato e lo scanner usano 8897, mentre la regola di allerta genera match su 8898.

Il precedente ENDLESSDOORS e i modelli coinvolti

ENDLESSDOORS (CVE-2026-66747) era stato divulgato il 5 agosto. La scheda NVD ufficiale riporta un CVSS v3 di 9,8 con vettore CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H e classe CWE-506, codice malevolo incorporato. Secondo la scheda, è presente in ogni build pubblicata della linea di prodotti. Il componente è lo strumento open source ycsunjane/rctl compilato come pacchetto OpenWrt librctl.so, avviato all’avvio ed eseguito come root con nome processo kworker, per confondersi con i thread kernel [kworker/*]. Non apre porte in ascolto: effettua collegamenti in uscita in chiaro TCP verso un C2 hardcoded, sulla porta 7000 per i comandi e 7001 per la shell interattiva, senza autenticazione né cifratura, ripetendo il contatto circa ogni 35 secondi.

Le advisory per i due nuovi impianti elencano numerosi modelli e build firmware. Per DARKLANTERN figurano Zbtlink WE1326, WE357, WE5926, WE5926-WD, WE826-Q, WE826-T2, WE826-WD, WG108, WG3526 con firmware 19.1101, WE2426-C con firmware 19.1112, WE5926-EC_QP con firmware 20.0516, WF3526-P con firmware 19.051, e modelli di vendor non identificati come CTN720-W1, LF-1541, MT7620N e WRC1. Per SPEAKINGSTONE compaiono L3_V2_8 con firmware 3.0.0.4.528, WE826-T2 con firmware 19.1101, ZBT-7628 e ZBT-ZBT7621 con firmware 1.0.x, oltre a modelli MoreQuick (MQAC-7620, MQAC-7620A, MQAP-7620, MQAP-7620A, MQAP-7628) e a numerosi modelli di vendor non identificati. Le pagine advisory mostrano le build come limiti superiori, mentre i record CVE riportano ciascun firmware come singola build esatta e impostano lo stato di ogni altra versione a “sconosciuto”. Nessuna advisory indica una versione correttiva.

MOFI Network, che sviluppa firmware proprio per la stessa piattaforma, ha un’immagine esaminata da VulnCheck risultata priva dei tre impianti.

Cosa può fare chi legge: mitigazioni e indicatori

Non esiste al momento un rilascio firmware correttivo per SPEAKINGSTONE e DARKLANTERN. VulnCheck raccomanda di bloccare il traffico in ingresso verso UDP/9992 al perimetro di rete, chiudendo così il listener di DARKLANTERN finché non sarà disponibile una patch. Per SPEAKINGSTONE, la raccomandazione è di bloccare e generare alert sugli endpoint sia in egress sia a livello di resolver per i domini C2, e di trattare la LAN del router come non fidata.

Per verificare se un dispositivo è prodotto da ZBT si possono usare i prefissi MAC IEEE 78:A3:51 e F8:5E:3C. VulnCheck ha pubblicato regole Suricata e YARA; chi le usa deve tenere conto della discrepanza sulla porta di risposta di DARKLANTERN (8897 nello scanner, 8898 nella regola).

Gli indicatori di compromissione pubblicati includono i domini www.ac-link[.]com e www.findmyipaddr[.]com, l’IP 47.107.224[.]89, le porte UDP/9992, UDP/8897 (o 8898) e UDP/10000. I servizi coinvolti sono infosrvd, yunmgrd e inetdetect; i percorsi rilevanti sono /etc/exec/cmd, /tmp/info.txt e /tmp/yunclient.conf. Gli hash SHA-256 dei binari sono b77811db4d218c65670a6c9a5b33c30ff81c6d779e15d658643138771178a818 per yunmgrd, 7e2e036fec2fe7ab4bbd43978d9296563894c92a112f5ac2f39957f12108e245 per infosrvd e ae6c356f1f09260b859f84d994ef8423540a6c0bdf98510d86b85834283e4926 per inetdetect.

Cataloghi e risposta del vendor

Il catalogo CISA Known Exploited Vulnerabilities nella versione 2026.08.27, verificata il 28 agosto, non contiene nessuno dei tre CVE relativi a ZBT. La pagina KEV di CISA elenca 1685 risultati complessivi, ma nessuna voce riguarda Zbtlink o Shenzhen Zhibotong Electronics. Di conseguenza, non è prevista una scadenza di remediation per le agenzie federali statunitensi per questi specifici CVE.

Diverso è il catalogo di VulnCheck, che ha inserito CVE-2026-74233 nel proprio Known Exploited Vulnerabilities. I criteri pubblicati da VulnCheck richiedono che una vulnerabilità sia “pubblicamente segnalata come sfruttata in the wild”. Il progetto CISA Vulnrichment, registrato per lo stesso CVE il 27 agosto, valuta invece lo sfruttamento come proof-of-concept: la documentazione dell’agenzia definisce tale stato come esistenza di un PoC pubblico al momento dell’analisi.

Zbtlink ha risposto solo in merito a ENDLESSDOORS. In una nota sul sito e tramite portavoce il 6 agosto, l’azienda ha affermato che il componente serve esclusivamente come strumento di supporto tecnico post-vendita, usato solo su richiesta esplicita e autorizzazione del cliente, che “non è mai stato utilizzato per accessi non autorizzati” e che sarebbe generalmente presente solo su unità campione per il debug del software. Non risultano dichiarazioni pubbliche su yunmgrd o infosrvd.

Il 28 agosto le pagine di download firmware di Zbtlink erano attive e servivano otto immagini datate 17 agosto, tra cui build per WE826-T2 e WE2426-C, entrambi modelli citati nelle nuove advisory. The Hacker News ha contattato Zbtlink per sapere se il firmware corrente contenga ancora i due componenti e VulnCheck per le prove alla base della catalogazione: alla pubblicazione non risultano risposte.