Cloudflare, cosa è successo il 18 novembre (mistergadget.tech)
Un bug nel cuore dei sistemi di gestione automatica ha messo offline mezza Internet per oltre cinque ore. L’azienda spiega com’è successo e cosa cambierà.
Lunedì 18 novembre non è stato un lunedì qualsiasi per Internet. Poco dopo mezzogiorno, una parte significativa del web globale ha smesso di funzionare. Siti inaccessibili, servizi in crash, app bloccate: un cortocircuito digitale che ha colpito milioni di utenti. E il nome al centro della tempesta era uno solo: Cloudflare, la società che gestisce parte cruciale dell’infrastruttura di rete mondiale, tra CDN, sicurezza e protezione anti-DDoS.
Inizialmente si è pensato a un attacco informatico su larga scala. La realtà, però, si è rivelata più prosaica ma non meno preoccupante: un errore interno nei sistemi dati dell’azienda. A confermarlo è stato direttamente Matthew Prince, CEO e cofondatore, con un lungo post tecnico pubblicato sul blog ufficiale di Cloudflare.
“Non c’è stato alcun attacco. È stato un nostro errore — un difetto di configurazione che si è propagato a livello globale in pochi minuti.”
Il cortocircuito digitale partito da un database
Tutto è cominciato intorno alle 12:05 italiane, quando un’operazione di routine su un cluster ClickHouse, il sistema che alimenta i dati per l’analisi e la sicurezza, ha generato un effetto imprevisto. L’obiettivo era migliorare la gestione dei permessi interni, ma qualcosa è andato storto: il database ha cominciato a duplicare righe di codice in un file chiave, chiamato feature file.
Quel file serve al sistema di Bot Management, la tecnologia che distingue il traffico umano da quello automatizzato. In pratica, un singolo file corrotto ha mandato in tilt il cervello che filtra miliardi di richieste ogni secondo. Il file si rigenera e si propaga automaticamente in tutto il network Cloudflare, e in pochi minuti la versione difettosa ha raggiunto nodi in ogni continente, generando errori a catena su larga scala. Dalle 12:20, è stato il caos: migliaia di siti e app sono andati offline restituendo errori 502 e 520. Il disastro era iniziato.
La diagnosi: un’anomalia scambiata per un attacco
In quelle prime fasi, i team interni non sapevano ancora di cosa si trattasse. Il traffico irregolare e il collasso simultaneo dei servizi ha fatto pensare a un cyberattacco sincronizzato, anche perché — per una bizzarra coincidenza — la pagina di stato ufficiale di Cloudflare era down nello stesso momento.
Ma presto è emerso che la causa era ben diversa. Il feature file difettoso aveva superato le dimensioni consentite e mandato in crash i processi interni che ne gestivano la lettura, bloccando l’intero proxy centrale. Da quel punto, l’interruzione si è propagata come una valanga: la CDN, il sistema di autenticazione e perfino la dashboard aziendale sono andate in blocco.
Chi era già loggato poteva continuare a operare, ma nuovi accessi e processi API fallivano in continuazione. Perfino Turnstile (il sistema CAPTCHA) e Workers KV hanno smesso di rispondere. Gli errori hanno generato un sovraccarico dei sistemi di debug, che nel tentativo di loggare tutto hanno finito per peggiorare ulteriormente il collasso.
Il ritorno online: cinque ore di lavoro chirurgico
Alle 13:00, il team di emergenza ha iniziato a isolare la causa. Poco dopo, sono stati creati bypass di emergenza per i moduli più colpiti, in modo da ristabilire parzialmente i flussi. Ma solo alle 14:24 il colpevole è stato identificato con certezza: quel feature file anomalo stava continuando a replicarsi.
Alle 14:30, Cloudflare ha distribuito una versione precedente e corretta del file su tutta la rete globale. Da quel momento la situazione ha iniziato lentamente a stabilizzarsi, fino al pieno ripristino, avvenuto intorno alle 18:06 italiane. Nel frattempo, l’azienda ha monitorato in tempo reale la progressiva riduzione degli errori 5xx e il ritorno alla normalità dei servizi come Access, Email Security e Bot Management, riportando gradualmente il traffico a livelli regolari.
Cosa farà Cloudflare per evitare un nuovo disastro
Il blackout ha messo a nudo la fragilità di una rete ormai troppo automatizzata. Prince ha annunciato una revisione profonda dei processi di aggiornamento interni, introducendo:
- Kill switch globali, in grado di interrompere all’istante la distribuzione di un file difettoso;
- Test di integrità preventiva su ogni file di configurazione prima che venga propagato;
- Controlli di priorità sui sistemi di logging, così da evitare che i report di errore intasino risorse critiche;
- Audit interno sul core proxy, per rendere più resiliente il comportamento del sistema in presenza di input anomali.
“Abbiamo avuto la peggiore interruzione dal 2019,” ha scritto Prince.
“È inaccettabile e ne siamo pienamente responsabili. Ci impegniamo a imparare da quanto accaduto e a rafforzare l’intero ecosistema Cloudflare.”
Una lezione per l’intera rete globale
L’incidente ha ricordato a tutti quanto Internet sia centralizzata attorno a pochi nodi infrastrutturali. Un singolo errore — un file duplicato, un bug imprevisto — può avere effetti a catena su scala mondiale. Cloudflare non è nuova a blackout del genere, ma mai negli ultimi sei anni si era verificato un crash così esteso.
E, paradossalmente, proprio la velocità e l’automazione che rendono la rete Cloudflare efficiente sono gli stessi elementi che hanno amplificato la crisi. Oggi la società si presenta come più consapevole, ma anche più vulnerabile: un colosso che ha riscoperto il peso delle proprie linee di codice. Il web, intanto, ha ripreso a respirare. Ma l’eco di quel lunedì nero resta un monito per tutti: non serve un attacco per fermare Internet — basta un errore umano.
