Mettetevi comodi. Questa che state per leggere è una storia che ci fa capire come stia per cambiare un’epoca per la tecnologia: Telnet è uno dei più vecchi protocolli di rete, sotto attacco per via di una vulnerabilità, con una storia che sembra un romanzo mystery e che rende tutto più intrigante perché avvolto dal segreto, con le dinamiche che ruotano attorno ai big della tecnologia, la backbone di Internet, le reti private dei fornitori cloud.
Un vero giallo, insomma, di quelli da mettersi in poltrona e leggere con calma la storia, come se fosse un romanzo. Perché alla fine quello è: un romanzo moderno di tecnologia, mistero e pericolo digitale. La cui trama è apparentemente semplice: il 14 gennaio 2026 il traffico Telnet mondiale è crollato del 59 per cento in un’ora. Sei giorni dopo è emersa una vulnerabilità critica. La coincidenza solleva domande inquietanti sul futuro di uno dei protocolli più antichi di Internet. Ma vediamo i dettagli.
Era una notte buia e tempestosa…
Il 14 gennaio 2026 alle 21:00 UTC (cioè l’ora di Greenwich) qualcosa è cambiato nella trama invisibile di Internet. I sensori della rete di osservazione globale di GreyNoise hanno registrato un crollo improvviso del traffico Telnet mondiale. Non una riduzione graduale, non un’attenuazione fisiologica, ma una caduta a strapiombo. Un’ora prima scorrevano circa 74mila sessioni ogni 60 minuti, un’ora dopo ne restavano 22mila, poi 11mila, e alla fine il livello si è stabilizzato lì.
Sei giorni più tardi, il 20 gennaio, l’avviso di sicurezza per la vulnerabilità CVE-2026-24061 è comparso sulla mailing list oss-security. Il 26 gennaio la Cybersecurity and Infrastructure Security Agency degli Stati Uniti l’ha aggiunta al catalogo delle vulnerabilità sfruttate attivamente. Insomma, prima il crollo, poi la vulnerabilità. Sul piano temporale, il primo evento non può essere la conseguenza del secondo. Ma il solo fatto che i due fenomeni siano così vicini solleva domande che non trovano risposte facili.
GreyNoise aveva già raccontato le prime diciotto ore di attività malevola seguita alla divulgazione della falla il 22 gennaio. Questa storia riguarda qualcosa di diverso: il cambiamento strutturale nel traffico Telnet globale che ha preceduto la pubblicazione della vulnerabilità. E la possibilità inquietante che i due eventi non siano indipendenti.
Il crollo
Dal primo dicembre 2025 al 14 gennaio 2026, GreyNoise aveva osservato una media di circa 914mila sessioni Telnet giornaliere su 51,2 milioni di sessioni totali. Questa era la linea di base, il cento per cento da cui partire. Il 14 gennaio alle 21:00 UTC il volume orario è precipitato del 65 per cento in un solo minuto. Nel giro di due ore era calato dell’83 per cento. Il nuovo livello si è assestato attorno alle 373mila sessioni al giorno, una riduzione sostenuta del 59 per cento che persiste ancora oggi.
Non è stata una transizione graduale. I dati orari attorno al punto di inflessione raccontano tutto: alle 19:00 UTC del 14 gennaio le sessioni erano 73.900, alle 20:00 erano 64.722, alle 21:00 erano crollate a 22.460. Alle 22:00 erano scese a 11.325, l’83 per cento sotto la linea di base. Alle 23:00 il nuovo livello si era stabilizzato a 11.147 sessioni.
Questo tipo di funzione a gradino, che si propaga in una singola finestra temporale di un’ora, si può interpretare solo come una modifica di configurazione sull’infrastruttura di routing. Non come una deriva comportamentale nelle popolazioni di scanner. Non come un incidente tecnologico. È un cambiamento voluto e perseguito con freddezza. Ma perché? Come mai?
Cosa è diventato silenzioso
Diciotto reti autonome con volumi significativi di traffico Telnet prima del crollo sono scese a zero assoluto dopo il 15 gennaio. Alcuni nomi spiccano nella lista: Vultr con 382mila sessioni prima del crollo e poi più niente, Cox Communications con 150mila sessioni scomparse, Charter e Spectrum con 141mila, British Telecom con 127mila.
Cinque interi paesi sono svaniti dai dati Telnet di GreyNoise: Zimbabwe, Ucraina, Canada, Polonia ed Egitto. Non ridotti, proprio azzerati. Nel frattempo i grandi fornitori cloud sono rimasti sostanzialmente inalterati o sono persino aumentati. Amazon Web Services è salito del 78 per cento, Contabo del 90 per cento, DigitalOcean è rimasto essenzialmente invariato con un incremento del 3 per cento.
Va conosciuto un altro particolare tecnico, per capire. I fornitori cloud dispongono di estesi sistemi di peering privato presso i principali punti di interscambio Internet. I sistemi di peering privato aggirano i percorsi tradizionali della backbone di transito (in pratica: le autostrade principali di Internet). I fornitori di servizi Internet residenziali e aziendali di solito non li hanno: usano le backbone pubbliche. Tradotto: il traffico si è spostato in maniera massiva.
Dove si trova il filtro
La distribuzione dei dati punta verso una interpretazione molto semplice e diretta: uno o più fornitori di transito di livello uno nordamericani (i più grandi al mondo) hanno implementato il filtraggio della porta 23. Il momento, le 21:00 UTC corrispondenti alle 16:00 del fuso orientale degli Stati Uniti, è compatibile con una finestra di manutenzione tipica dei centri di calcolo statunitensi. I fornitori residenziali americani sono stati completamente devastati, mentre i fornitori cloud nello stesso continente hanno aggirato qualsiasi cosa sia cambiata tramite peering. Come mai?
Vediamo gli ultimi numeri che ci permettono di concludere il ritratto di quel che è successo. Verizon e UUNET sono calati del 79 per cento, e come principale backbone di primo livello questo è compatibile con il fatto che sia l’entità filtrante o si trovi direttamente a monte di una di queste grandi reti. È un filtro coordinato in anticipo insomma: non c’è conferma ufficiale, ma i dati puntano in quella direzione.
Il 21 per cento di traffico residuo su questa rete rappresenterebbe percorsi che non transitano per i collegamenti filtrati. Ad esempio, i paesi che si affidano a rotte backbone transatlantiche o transpacifiche per raggiungere l’infrastruttura ospitata negli Stati Uniti sono stati colpiti più duramente. I paesi con forte peering diretto europeo sono rimasti essenzialmente inalterati.
Invece, i fornitori backbone cinesi sono scesi uniformemente del 59 per cento. Questa uniformità suggerisce che il filtro si trovi sul lato statunitense dei collegamenti transpacifici piuttosto che all’interno della Cina. Se si fosse trattato di un’azione del firewall cinese, ci si aspetterebbe un impatto asimmetrico tra i vettori cinesi e un taglio più netto.
Poi è arrivata la vulnerabilità
Ecco, se avete seguito fino qui, avete visto le conseguenze. Ma le conseguenze di cosa? Di un documento che in realtà è stato pubblicato dopo le sue conseguenze, e non prima. Perché? Andiamo con ordine.
Il CVE-2026-24061 (la nomenclatura standard dei rapporti sulle vulnerabilità di cybersicurezza) è un bypass critico dell’autenticazione in GNU Inetutils telnetd con punteggio CVSS di 9,8. La falla è un’iniezione di dati (in realtà, gli argomenti delle stringhe di comando) nel modo in cui il demone Unix/Linux telnetd gestisce la variabile d’ambiente USER durante la negoziazione delle opzioni Telnet. Un attaccante invia la stringa con un argomento (“-f root” come valore del nome utente) e il comando “login” salta a pie’ pari e in maniera totalmente obbediente l’autenticazione, consegnando una shell di root all’attaccante da remoto. Nessuna credenziale richiesta, nessuna interazione dell’utente. Il codice vulnerabile è stato introdotto con un commit del 2015 ed è rimasto nascosto per quasi undici anni.
La cronologia degli eventi è significativa: il 14 gennaio alle 21:00 UTC inizia il crollo del traffico Telnet sulla backbone. Il 20 gennaio l’avviso per CVE-2026-24061 viene pubblicato su oss-security. Il 21 gennaio viene pubblicata la voce nel database nazionale delle vulnerabilità, GreyNoise attiva il tag di monitoraggio e viene osservato il primo sfruttamento. Il 22 gennaio GreyNoise pubblica un’analisi delle prime diciotto ore di attività malevola. Il 26 gennaio la CISA aggiunge CVE-2026-24061 al catalogo delle vulnerabilità sfruttate.
Adesso avete visto? Il divario di sei giorni tra il crollo del traffico Telnet (avvenuto prima, in maniera preventiva) e la divulgazione pubblica della vulnerabilità (già scoperta ma evidentemente non ancora sfruttata da nessuno) è la parte interessante. A prima vista il crollo non può essere stato causato dalla divulgazione della vulnerabilità perché il crollo è avvenuto prima. Ma causato da non è l’unica relazione che vale la pena considerare.
L’ipotesi
Le tempistiche di divulgazione responsabile non iniziano alla pubblicazione. Il ricercatore che ha trovato la falla ha segnalato il problema il 19 gennaio secondo le fonti pubbliche. Ma il coordinamento che porta alle patch pronte, agli avvisi redatti e alla CISA preparata ad aggiungere qualcosa al catalogo entro sei giorni dalla pubblicazione di solito inizia prima del giorno precedente alla divulgazione.
Ecco cosa potrebbe essere successo: la notifica anticipata di una vulnerabilità banalmente sfruttabile che consente accesso root non autenticato sui daemon Telnet ha raggiunto parti con la capacità di agire a livello di infrastruttura. Un fornitore di backbone o di transito, probabilmente rispondendo a una richiesta coordinata oppure agendo sulla propria valutazione, ha implementato il filtraggio della porta 23 sui collegamenti di transito. Il filtraggio è entrato in vigore il 14 gennaio. La divulgazione pubblica è seguita il 20 gennaio.
Questo spiegherebbe il divario temporale tra notifica anticipata, risposta infrastrutturale e divulgazione pubblica. Spiegherebbe la specificità del filtraggio sulla porta 23 TCP e non un cambiamento generale di routing. Spiegherebbe la topologia dell’impatto con i percorsi dipendenti dal transito colpiti e i percorsi con peering diretto no. Spiegherebbe la natura sostenuta del fenomeno visto che il filtro è ancora attivo settimane dopo.
Il mondo dopo il crollo
Il paesaggio Telnet dopo il 14 gennaio mostra uno schema ricorrente a dente di sega con picchi periodici seguiti da avvallamenti. Questo potrebbe indicare l’applicazione intermittente del filtro, oscillazioni di routing attorno all’infrastruttura filtrante o campagne di scanner che utilizzano percorsi non interessati dal filtro. Le medie settimanali sostengono invece la teoria della storia così come è stata spiegata: dalla prima settimana di dicembre con oltre un milione di sessioni giornaliere si è passati alla settimana del 19 gennaio con 363mila sessioni, il 40 per cento della linea di base.
Adesso il livello operativo si attesta attorno a un terzo della linea di base precedente al crollo e la tendenza è ancora leggermente discendente. Se si gestiscono daemon di “GNU Inetutils telnetd” (quelli che sono il cuore open source di internet) in qualsiasi parte del mondo, e data la finestra di undici anni ce ne sono molti anche nei sistemi embedded, nelle appliance di rete e nelle installazioni Linux legacy, occorre aggiornare alla versione corretta o disabilitare completamente il servizio.
La scadenza per la correzione delle agenzie federali americane secondo la CISA è il 16 febbraio 2026. GreyNoise ha osservato tentativi di sfruttamento entro poche ore dalla divulgazione e la campagna ha raggiunto il picco di circa 2600 sessioni al giorno all’inizio di febbraio prima di diminuire. Se qualcuno dei big a monte di una parte significativa dell’infrastruttura di transito di Internet ha deciso che il traffico Telnet non vale più la pena di essere trasportato, probabilmente è la decisione giusta. Ma è anche la fine del Telnet.
La rete cambia così, come un mistero di Agatha Christie che poi si trasforma in un giallo internazionale tra superpotenze della rete. Un mistero e uno scontro sotterraneo del quale nessuno racconta quasi mai nulla, ma che invece cambia il mondo nel quale viviamo.
