Telnet scompare in una notte: il crollo globale del 2026 per salvare milioni di dispositivi

Il 14 gennaio 2026 il traffico Telnet globale crolla improvvisamente. Sei giorni dopo emerge la devastante vulnerabilità CVE-2026-24061: possibile mitigazione preventiva a livello backbone prima della disclosure pubblica.

Com’è possibile che un protocollo di rete come Telnet, che esiste dal 1969 e nella sua forma più matura e standardizzata dal 1983, molto prima del World Wide Web (agosto 1991), sia improvvisamente scomparso in una fredda giornata dell’inverno 2026? Eppure, i ricercatori di GreyNoise Labs spiegano che il 14 gennaio 2026 si è verificata una caduta improvvisa e sostenuta del traffico Telnet: un crollo non progressivo, non attribuibile a fenomeni di lungo periodo come il naturale declino del protocollo.

In quella giornata, secondo i dati raccolti da sensori distribuiti sulla rete Internet a livello globale, si è consumato un fenomeno del tutto anomalo che ha cancellato qualunque trasferimento dati via Telnet dopo tanti anni di onorato servizio.

Sei giorni dopo è stata resa pubblica la vulnerabilità critica CVE-2026-24061, un bypass di autenticazione nel daemon telnetd di GNU Inetutils con impatto devastante (CVSS 9,8).

La sequenza temporale tra i due eventi solleva interrogativi che vanno oltre la mera coincidenza statistica e apre uno spazio di riflessione su come le decisioni infrastrutturali possano anticipare — o mitigare — minacce informatiche non ancora divulgate pubblicamente.

Un’anomalia di rete non compatibile con il declino naturale di Telnet

Gli specialisti di GreyNoise Labs, società che abbiamo citato anche di recente presentando il loro test di verifica degli indirizzi IP pubblici, osservano che il comportamento rilevato il 14 gennaio  scorso non è coerente con l’evoluzione storica del protocollo Telnet. Negli ultimi due decenni il traffico Telnet ha seguito una traiettoria discendente, ma con un ritmo graduale e oscillazioni stagionali legate alle campagne di scanning e alla diffusione di botnet basate su credenziali deboli.

Ciò che è stato registrato nel 2026 è un repentino azzeramento globale del traffico Telnet: dal punto di vista dell’ingegneria delle reti, quanto avvenuto è compatibile con una modifica di configurazione su larga scala, applicata a livello di backbone o di grandi provider di transito.

La natura “istantanea” del fenomeno suggerisce un cambiamento operativo distribuito attraverso sistemi di filtering o policy routing su nodi chiave della rete globale. Un’azione di questo tipo può essere propagata in tempi molto rapidi se implementata su infrastrutture Tier 1, con effetti immediatamente visibili sui percorsi di transito intercontinentali.

CVE-2026-24061: una vulnerabilità latente per oltre un decennio

Sei giorni dopo il crollo del traffico, la divulgazione pubblica della vulnerabilità CVE-2026-24061, come spiegato nell’articolo citato in precedenza, ha fatto emergere una falla nella procedura di autenticazione introdotta nel 2015 e rimasta inosservata per circa 11 anni.

Il difetto consiste in una iniezione di argomenti nella gestione della variabile d’ambiente USER durante la negoziazione delle opzioni Telnet: un aggressore può fornire il valore -f root, inducendo il processo di login a saltare l’autenticazione e a concedere una shell con privilegi massimi.

La combinazione di fattori rende la vulnerabilità estremamente pericolosa: assenza di autenticazione, assenza di interazione utente e possibilità di sfruttamento remoto diretto. In presenza di un servizio Telnet esposto, l’attaccante ottiene accesso root immediato senza conoscere credenziali. Considerando la diffusione di sistemi embedded, appliance legacy e ambienti industriali ancora dipendenti da Telnet, l’impatto potenziale è significativo e difficilmente stimabile con precisione.

Correlazione temporale e ipotesi di notifica preventiva

Il punto più delicato dell’analisi risiede nella relazione temporale tra il crollo del traffico Telnet osservato e la divulgazione della vulnerabilità dopo appena qualche giorno.

GreyNoise ricorda che i processi di responsible disclosure (segnalazione responsabile, in privato, delle vulnerabilità di sicurezza) raramente iniziano nel momento in cui la vulnerabilità diventa pubblica: includono fasi di segnalazione, coordinamento con vendor, preparazione di patch e pianificazione di advisory ufficiali.

È quindi plausibile ipotizzare che informazioni preliminari sulla vulnerabilità critica di Telnet, facilmente sfruttabile e con impatto sistemico, siano state condivise con attori dotati di capacità operative sull’infrastruttura globale. In tale contesto, l’implementazione anticipata di filtri sul traffico Telnet avrebbe rappresentato una misura preventiva volta a ridurre la superficie di attacco prima della diffusione pubblica dei dettagli tecnici.

I tecnici GreyNoise aggiungono che l’interpretazione non può essere dimostrata in modo definitivo senza conferme dirette dai provider coinvolti. Tuttavia, la sequenza temporale — intervento infrastrutturale, pubblicazione CVE, osservazione di campagne di sfruttamento — costituisce una concatenazione logica coerente con un modello di mitigazione preventiva coordinata.

Dati di scanning globale (Shodan, Censys, Shadowserver e osservazioni accademiche) indicano che circa 1-3 milioni di host su Internet espongono ancora il servizio Telnet (porta 23) in modo direttamente raggiungibile.

Implicazioni strategiche per la sicurezza delle infrastrutture Internet

Indipendentemente dal rapporto causale, l’episodio evidenzia una tendenza emergente: la sicurezza di protocolli legacy non è più demandata esclusivamente agli endpoint, ma gestita sempre più a livello di infrastruttura di transito.

Filtrare il traffico su porte storicamente associate a protocolli insicuri rappresenta una forma di difesa collettiva che riduce l’efficacia di worm e botnet basati su scansioni di massa.

L’approccio introduce però interrogativi in termini di governance: chi decide quando un protocollo è “troppo insicuro” per essere trasportato sulla rete pubblica? Quali sono le implicazioni per ambienti industriali o legacy che non possono migrare rapidamente verso alternative più sicure come SSH?

Il rischio è che misure globali, pur giustificate dal punto di vista della sicurezza, producano effetti collaterali su sistemi critici non facilmente aggiornabili.

Ti consigliamo anche

Link copiato negli appunti