Introduzione
Il 18 novembre 2025 alle 11:20 UTC, la rete di Cloudflare ha subito un'interruzione significativa che ha impedito la consegna del traffico di rete per diverse ore. L'incidente, il più grave dal 2019, ha colpito milioni di siti web e servizi che si affidano all'infrastruttura CDN di Cloudflare. Gli utenti che tentavano di accedere ai siti dei clienti Cloudflare hanno ricevuto pagine di errore HTTP 5xx che indicavano un malfunzionamento interno della rete.
La causa principale non è stata un attacco informatico o attività malevole, ma un errore nella gestione dei permessi di un database ClickHouse utilizzato dal sistema Bot Management. Questo ha generato un file di configurazione delle feature di dimensioni doppie rispetto al normale, che una volta propagato a tutti i server della rete ha causato il crash del software di routing.
Cronologia dell'Incidente
L'interruzione è iniziata alle 11:20 UTC quando il volume di codici di errore HTTP 5xx è aumentato drasticamente rispetto al livello base normale. Il comportamento anomalo del sistema ha inizialmente fatto sospettare un attacco DDoS su scala massiccia, ritardando l'identificazione della vera causa.
Un aspetto peculiare dell'incidente è stata la natura fluttuante degli errori: il sistema si riprendeva periodicamente per poi fallire di nuovo ogni cinque minuti. Questo pattern era causato dal fatto che il file di configurazione veniva rigenerato ogni cinque minuti da una query su un cluster ClickHouse che stava venendo gradualmente aggiornato. Solo i nodi già aggiornati generavano dati errati, creando un'alternanza tra file buoni e cattivi.
Il traffico principale ha ripreso a fluire normalmente alle 14:30 UTC, dopo che il team ha identificato correttamente il problema e sostituito il file problematico con una versione precedente funzionante. Tutti i sistemi sono tornati operativi completamente alle 17:06 UTC, dopo aver mitigato il carico aumentato su varie parti della rete.
L'Origine Tecnica del Problema
Il sistema Bot Management di Cloudflare utilizza un modello di machine learning per generare punteggi bot per ogni richiesta che attraversa la rete. Questo modello si basa su un file di configurazione delle "feature" che viene aggiornato ogni pochi minuti per reagire rapidamente alle variazioni nel traffico Internet e ai nuovi tipi di bot.
Alle 11:05 UTC è stata implementata una modifica al sistema di gestione dei permessi del database ClickHouse. L'obiettivo era migliorare la sicurezza e l'affidabilità delle query distribuite, rendendo esplicito l'accesso alle tabelle sottostanti che gli utenti avevano già implicitamente. Prima della modifica, gli utenti vedevano solo le tabelle nel database "default"; dopo la modifica, potevano vedere anche i metadati delle tabelle nel database "r0" dove i dati sono effettivamente memorizzati.
La query SQL utilizzata per generare il file di configurazione delle feature non filtrava per nome del database. Di conseguenza, dopo la modifica ha iniziato a restituire righe duplicate per ogni colonna, una per il database "default" e una per "r0", raddoppiando efficacemente il numero di feature nel file finale.
Il Limite di Memoria e il Panic del Sistema
Ogni modulo del servizio proxy di Cloudflare ha limiti impostati per evitare il consumo illimitato di memoria e per preallocare memoria come ottimizzazione delle performance. Il sistema Bot Management aveva un limite fissato a 200 feature, ben al di sopra dell'utilizzo normale di circa 60 feature.
Quando il file errato con oltre 200 feature è stato propagato ai server, questo limite è stato superato, causando un panic nel codice Rust di FL2. Il codice chiamava unwrap() su un risultato di errore senza gestirlo, generando il messaggio: "thread fl2_worker_thread panicked: called Result::unwrap() on an Err value". Questo panic si traduceva in errori HTTP 5xx per gli utenti finali.
I clienti sulla nuova versione del proxy FL2 hanno osservato errori HTTP 5xx, mentre quelli sulla versione precedente FL non vedevano errori ma ricevevano punteggi bot pari a zero per tutto il traffico, causando numerosi falsi positivi per chi aveva regole configurate per bloccare i bot.
Servizi Impattati dall'Interruzione
L'outage ha colpito diversi servizi core e prodotti di Cloudflare:
- CDN e servizi di sicurezza principali: codici di stato HTTP 5xx per il traffico dei clienti
- Turnstile: impossibilità di caricare il servizio di verifica anti-bot
- Workers KV: elevato numero di errori HTTP 5xx sulle richieste al gateway front-end
- Dashboard: la maggior parte degli utenti non è riuscita ad effettuare il login a causa dell'indisponibilità di Turnstile
- Email Security: perdita temporanea di accesso a una fonte di reputazione IP, riducendo l'accuratezza del rilevamento spam
- Access: errori di autenticazione diffusi per la maggior parte degli utenti dall'inizio dell'incidente fino al rollback
Oltre agli errori HTTP 5xx, si è osservato un aumento significativo della latenza delle risposte CDN. Questo era dovuto al consumo elevato di CPU da parte dei sistemi di debugging e osservabilità, che automaticamente arricchiscono gli errori non gestiti con informazioni aggiuntive per il debug.
La Soluzione e il Ripristino
Alle 13:05 UTC, il team ha implementato un bypass per Workers KV e Cloudflare Access, facendoli tornare a una versione precedente del proxy core. Sebbene il problema fosse presente anche nelle versioni precedenti, l'impatto era minore.
Alle 14:24 UTC, dopo aver identificato con certezza che il file di configurazione Bot Management era il trigger dell'incidente, il team ha bloccato la creazione e propagazione di nuovi file. Un test con la versione precedente del file ha confermato il successo del recovery.
Alle 14:30 UTC, un file di configurazione Bot Management corretto è stato distribuito globalmente e la maggior parte dei servizi ha iniziato a operare correttamente. Il traffico principale è tornato a fluire normalmente. Le ore successive sono state dedicate a riavviare i servizi rimanenti che erano entrati in uno stato errato, con il completo ripristino raggiunto alle 17:06 UTC.
Azioni Correttive e Prevenzione Futura
Cloudflare ha annunciato una serie di misure per prevenire incidenti simili in futuro:
- Hardening dell'ingestion dei file di configurazione: i file generati da Cloudflare saranno trattati con lo stesso rigore dei file generati dagli utenti, con validazione più stringente
- Kill switch globali potenziati: implementazione di interruttori di emergenza più efficaci per le feature
- Gestione delle risorse di sistema: eliminazione della possibilità che i core dump o altri report di errore possano sovraccaricare le risorse di sistema
- Revisione delle modalità di fallimento: analisi approfondita delle condizioni di errore in tutti i moduli del proxy core
- Miglioramento della gestione degli errori: evitare l'uso di
unwrap()su risultati di errore senza gestione appropriata
Conclusione
L'interruzione del 18 novembre 2025 rappresenta il peggior outage di Cloudflare dal 2019. Un cambiamento apparentemente innocuo nella gestione dei permessi del database ha innescato una catena di eventi che ha portato al crash di gran parte della rete. L'incidente sottolinea l'importanza di test approfonditi anche per modifiche che sembrano minori e della gestione robusta degli errori nei sistemi critici.
Cloudflare ha assunto piena responsabilità per l'interruzione, scusandosi per l'impatto su clienti e sull'ecosistema Internet in generale. L'azienda ha dimostrato trasparenza pubblicando un'analisi tecnica dettagliata e un piano d'azione concreto per prevenire incidenti simili. Per un'infrastruttura che gestisce una porzione significativa del traffico Internet globale, anche poche ore di downtime hanno conseguenze enormi per milioni di utenti e aziende in tutto il mondo.
FAQ
Quanto è durata l'interruzione di Cloudflare del 18 novembre 2025?
L'interruzione è iniziata alle 11:20 UTC e il traffico principale è tornato normale alle 14:30 UTC, per un totale di circa 3 ore. Il completo ripristino di tutti i sistemi è avvenuto alle 17:06 UTC.
Cosa ha causato il down di Cloudflare?
Un cambiamento nei permessi del database ClickHouse ha causato la generazione di un file di configurazione Bot Management di dimensioni doppie, superando il limite di memoria preallocato e causando il crash del sistema di routing.
L'interruzione di Cloudflare è stata causata da un attacco informatico?
No, l'incidente non è stato causato da attacchi DDoS, cyber attacchi o attività malevole di alcun tipo. È stato un errore interno nella configurazione del sistema.
Quali servizi sono stati colpiti dal down di Cloudflare?
I servizi impattati includono CDN core, Bot Management, Turnstile, Workers KV, Dashboard, Access ed Email Security. Gli utenti hanno ricevuto errori HTTP 5xx tentando di accedere ai siti ospitati su Cloudflare.
Come ha risolto Cloudflare l'interruzione del servizio?
Il team ha bloccato la propagazione del file errato e ha sostituito il file di configurazione Bot Management con una versione precedente funzionante, forzando poi un riavvio del proxy core.
Cloudflare aveva mai subito un'interruzione simile in passato?
Questo è stato il peggior outage di Cloudflare dal 2019. Negli ultimi 6+ anni non c'erano stati altri incidenti che avessero impedito al traffico core di fluire attraverso la rete.
Quali misure ha implementato Cloudflare per prevenire futuri down?
Cloudflare sta implementando validazione più stringente dei file di configurazione, kill switch globali migliorati, migliore gestione delle risorse di sistema e revisione delle modalità di fallimento in tutti i moduli del proxy.