Interruzione di Cloudflare del 18 novembre 2025

Il 18 novembre 2025 alle 11:20 UTC (tutti gli orari in questo blog sono espressi nel fuso orario UTC), la rete di Cloudflare ha iniziato a riscontrare problemi significativi nella distribuzione del traffico di rete principale. Questa problematica è apparsa agli utenti di Internet che tentavano di accedere ai siti dei nostri clienti sotto forma di pagina di errore, indicando un problema all'interno della rete di Cloudflare.

Il problema non è stato causato, direttamente o indirettamente, da un attacco informatico o da attività dannose di alcun genere, ma è stato innescato da una modifica alle autorizzazioni di uno dei nostri sistemi di database che ha fatto sì che il database generasse più voci in un "file di funzionalità" utilizzato dal nostro sistema di Bot Management. Tale file di funzionalità, a sua volta, è raddoppiato in dimensioni. Il file di funzionalità, più grande del previsto, è stato quindi propagato a tutte le macchine che compongono la nostra rete.

Il software in esecuzione su queste macchine per instradare il traffico attraverso la nostra rete legge questo file di funzionalità per mantenere aggiornato il nostro sistema Bot Management con le minacce in continua evoluzione. Il software aveva un limite di dimensione del file di funzionalità inferiore alla sua dimensione raddoppiata, causando un errore del software.

Dopo aver inizialmente sospettato erroneamente che i sintomi riscontrati fossero causati da un attacco DDoS su larga scala, abbiamo identificato correttamente il problema principale e siamo stati in grado di arrestare la propagazione del file di funzionalità più grande del previsto e sostituirlo con una versione precedente. Il traffico principale fluiva in gran parte normalmente entro le 14:30. Nelle ore successive, abbiamo lavorato per attenuare l'aumento del carico su varie parti della nostra rete, man mano che il traffico tornava rapidamente online. Alle 17:06 tutti i sistemi di Cloudflare funzionavano normalmente.

Ci scusiamo per l'impatto arrecato ai nostri clienti e a Internet in generale. Data l'importanza di Cloudflare nell'ecosistema di Internet, qualsiasi interruzione dei nostri sistemi è inaccettabile. Il fatto che ci sia stato un periodo di tempo in cui la nostra rete non è stata in grado di instradare il traffico è profondamente doloroso per ogni membro del nostro team. Sappiamo di avervi deluso oggi.

Questo articolo è un resoconto dettagliato di cosa è accaduto esattamente e quali sistemi e processi hanno fallito. È anche l'inizio, sebbene non la fine, di ciò che intendiamo fare per assicurarci che un'interruzione come questa non si verifichi più.

L'interruzione

Il grafico seguente mostra il volume di codici di stato HTTP di errore 5xx forniti dalla rete Cloudflare. Normalmente questo valore dovrebbe essere molto basso, ed è stato tale fino all'inizio dell'interruzione.

Il volume precedente alle 11:20 è la linea di base prevista di errori 5xx osservati nella nostra rete. Il picco e le successive fluttuazioni mostrano un errore del sistema causato dal caricamento di un file di funzionalità non corretto. È interessante notare che il nostro sistema si sarebbe poi ripreso per un certo periodo. Questo è stato un comportamento molto insolito per un errore interno.

La spiegazione era che il file veniva generato ogni cinque minuti da una query eseguita su un cluster di database ClickHouse, il quale veniva gradualmente aggiornato per migliorare la gestione delle autorizzazioni. Dati errati venivano generati solo se la query veniva eseguita su una parte del cluster che era stata aggiornata. Di conseguenza, ogni cinque minuti c'era la possibilità che venisse generato un set di file di configurazione, valido o non valido, e rapidamente propagato attraverso la rete.

Questa fluttuazione rendeva poco chiaro cosa stesse accadendo, poiché l'intero sistema si ripristinava per poi guastarsi di nuovo a causa della distribuzione di file di configurazione, a volte corretti, a volte errati, nella nostra rete. Inizialmente, tutto questo ci ha indotto a pensare che potesse trattarsi di un attacco. Alla fine, ogni nodo di ClickHouse generava il file di configurazione errato e la fluttuazione si è stabilizzata nello stato di errore.

Gli errori sono continuati fino a quando il problema sottostante è stato identificato e risolto a partire dalle 14:30. Abbiamo risolto il problema interrompendo la generazione e la propagazione del file di funzionalità non valido e inserendo manualmente un file valido noto nella coda di distribuzione dei file di funzionalità. Successivamente, abbiamo forzato il riavvio del nostro proxy principale.

La rimanente coda lunga nel grafico sopra è dovuta al riavvio, da parte del nostro team, dei servizi che erano entrati in uno stato anomalo, con il volume dei codici di errore 5xx tornato alla normalità alle 17:06.

Sono stati interessati i seguenti servizi:

Oltre a restituire errori HTTP 5xx, durante il periodo di impatto abbiamo osservato anche aumenti significativi nella latenza delle risposte dalla nostra CDN. Ciò era dovuto all'elevato consumo di CPU da parte dei nostri sistemi di debug e osservabilità, che migliorano automaticamente il processo di rilevamento degli errori non intercettati con informazioni di debug aggiuntive.

Come Cloudflare elabora le richieste e cosa non ha funzionato oggi

Ogni richiesta a Cloudflare segue un percorso ben definito all'interno della nostra rete. Potrebbe provenire da un browser che carica una pagina web, da un'app mobile che richiama un'API o da traffico automatizzato proveniente da un altro servizio. Queste richieste terminano prima al nostro livello HTTP e TLS, poi fluiscono nel nostro sistema proxy principale (che chiamiamo FL, "Frontline"), e infine attraverso Pingora, che esegue ricerche nella cache o recupera i dati dall'origine, se necessario.

In precedenza, abbiamo condiviso maggiori dettagli su come funziona il proxy principale qui. 

Quando una richiesta transita nel proxy principale, eseguiamo i vari prodotti di sicurezza e performance disponibili nella nostra rete. Il proxy applica la configurazione e le impostazioni univoche di ciascun cliente, dall'applicazione delle regole WAF e della protezione da attacchi DDoS, al routing del traffico verso la piattaforma per sviluppatori e R2. Lo realizza attraverso una serie di moduli specifici del dominio che applicano le regole di configurazione e i criteri al traffico in transito nel nostro proxy.

Uno di questi moduli, Bot Management, è stata la causa dell'interruzione odierna. 

Bot Management di Cloudflare include, tra gli altri sistemi, un modello di machine learning che utilizziamo per generare punteggi dei bot per ogni richiesta che transita nella nostra rete. I nostri clienti utilizzano i punteggi dei bot per controllare quali bot possono accedere ai loro siti o meno.

Il modello accetta come input un file di configurazione della "funzionalità". In questo contesto, una funzionalità è un tratto individuale utilizzato dal modello di machine learning per prevedere se la richiesta è stata automatizzata o meno. Il file di configurazione delle funzionalità è un insieme di singole funzionalità.

Questo file di funzionalità viene aggiornato con una cadenza di pochi minuti, pubblicato sull'intera nostra rete e ci consente di reagire alle variazioni dei flussi di traffico su Internet. Ci consente di reagire a nuovi tipi di bot e a nuovi attacchi di bot. È quindi fondamentale che venga implementato frequentemente e rapidamente, poiché i malintenzionati cambiano rapidamente le proprie tattiche.

Una modifica nel comportamento della query ClickHouse sottostante (spiegata di seguito) che genera questo file ha causato la presenza di un gran numero di righe di "funzionalità" duplicate. Questo ha modificato la dimensione del file di configurazione delle funzionalità, precedentemente di dimensioni fisse, causando l'attivazione di un errore da parte del modulo bot.

Di conseguenza, il sistema proxy principale che gestisce l'elaborazione del traffico per i nostri clienti ha restituito codici di errore HTTP 5xx per tutto il traffico che dipendeva dal modulo bot. Questo ha interessato anche Workers KV e Access, che si basano sul proxy principale.

Indipendentemente da questo incidente, eravamo e stiamo attualmente migrando il traffico dei nostri clienti a una nuova versione del nostro servizio proxy, internamente noto come FL2. Entrambe le versioni sono state interessate dal problema, sebbene l'impatto osservato fosse diverso.

I clienti distribuiti sul nuovo motore proxy FL2 hanno riscontrato errori HTTP 5xx. I clienti che utilizzavano il nostro motore proxy precedente, denominato FL, non riscontravano errori, ma i punteggi bot non venivano generati correttamente, di conseguenza tutto il traffico riceveva un punteggio bot pari a zero. I clienti con regole distribuite per bloccare i bot hanno riscontrato un elevato numero di falsi positivi. I clienti che non utilizzavano il nostro punteggio bot nelle loro regole non hanno subito alcun impatto.

A destabilizzarci e a farci supporre che potesse trattarsi di un attacco ha contribuito un altro sintomo che abbiamo rilevato: la pagina di stato di Cloudflare risultava irraggiungibile. La pagina di stato è ospitata completamente al di fuori dell'infrastruttura di Cloudflare, senza alcuna dipendenza da Cloudflare. Sebbene si sia rivelata una coincidenza, ciò ha indotto alcuni membri del team che stavano diagnosticando il problema a ritenere che un utente malintenzionato potesse aver preso di mira sia i nostri sistemi che la nostra pagina di stato. I visitatori della pagina di stato in quel momento hanno visualizzato un messaggio di errore:

Nella chat room interna degli incidenti, temevamo che questa potesse essere la continuazione della recente ondata di attacchi DDoS Aisuru ad alto volume:

Modifica del comportamento della query

Come menzionato in precedenza, una modifica nel comportamento della query sottostante ha fatto sì che il file di funzionalità contenesse un numero elevato di righe duplicate. Il sistema di database in questione utilizza il software ClickHouse.

Per fornire un contesto, è utile sapere come funzionano le query distribuite di ClickHouse. Un cluster ClickHouse è costituito da numerosi shard. Per interrogare i dati da tutti gli shard, usiamo le cosiddette tabelle distribuite (supportate dal motore di tabelle distribuito) in un database chiamato predefinito. Il motore distribuito interroga le tabelle sottostanti in un database r0. Le tabelle sottostanti sono il punto in cui i dati vengono memorizzati in ogni shard di un cluster ClickHouse.

Le query alle tabelle distribuite vengono eseguite tramite un account di sistema condiviso. Nell'ambito degli sforzi per migliorare la sicurezza e l'affidabilità delle nostre query distribuite, stiamo lavorando per farle eseguire con gli account utente iniziali.

Prima di oggi, gli utenti di ClickHouse vedevano le tabelle solo nel database predefinito quando interrogavano i metadati delle tabelle dalle tabelle di sistema ClickHouse come system.tables o system.columns.

Poiché gli utenti hanno già un accesso implicito alle tabelle sottostanti in r0, alle 11:05 abbiamo apportato una modifica per rendere esplicito questo accesso, in modo che gli utenti potessero visualizzare anche i metadati di queste tabelle. Assicurandosi che tutte le sottoquery distribuite possano essere eseguite con l'utente iniziale, i limiti delle query e le concessioni di accesso possono essere valutati in modo più preciso, evitando che una sottoquery errata da parte di un utente influenzi le altre.

La modifica spiegata sopra ha permesso a tutti gli utenti di accedere a metadati accurati relativi alle tabelle a cui hanno accesso. Purtroppo, in passato si presumeva che l'elenco di colonne restituito da una query come questa includesse solo il database "predefinito":

SELECT
name,
type
FROM system.columns
WHERE
table = 'http_requests_features'
order by name;

Si noti come la query non filtra in base al nome del database. Con l'implementazione graduale delle concessioni esplicite agli utenti di un determinato cluster ClickHouse, dopo la modifica delle 11:05, la query di cui sopra ha iniziato a restituire "duplicati" di colonne perché queste appartenevano a tabelle sottostanti archiviate nel database r0.

Questo, purtroppo, era il tipo di query eseguito dalla logica di generazione dei file di funzionalità di Bot Management per creare ogni "funzionalità" di input per il file menzionato all'inizio di questa sezione. 

La query precedente ha restituito una tabella di colonne come quella visualizzata (esempio semplificato):

Tuttavia, nell'ambito delle autorizzazioni aggiuntive concesse all'utente, a quel punto la risposta conteneva tutti i metadati dello schema r0, raddoppiando di fatto il numero di righe nella risposta e influenzando in definitiva il numero di righe (ossia funzionalità) nell'output del file finale. 

Preallocazione della memoria

Ogni modulo in esecuzione sul nostro servizio proxy prevede diversi limiti per evitare un consumo eccessivo di memoria e preallocare la memoria come ottimizzazione delle prestazioni. In questo caso specifico, il sistema Bot Management ha un limite al numero di funzionalità di machine learning utilizzabili in fase di runtime. Attualmente, tale limite è impostato su 200, un valore ben superiore al nostro utilizzo attuale di circa 60 funzionalità. È bene ribadire che il limite esiste perché, per motivi di prestazioni, preallochiamo memoria per le funzionalità.

Quando il file danneggiato con più di 200 funzionalità è stato propagato ai nostri server, è stato raggiunto questo limite, causando il blocco del sistema. Il codice FL2 Rust che esegue il controllo e ha causato l'errore non gestito è mostrato di seguito:

Questo ha causato il seguente blocco, che a sua volta ha generato un errore 5xx:

Il thread fl2_worker_thread si è bloccato: ha richiamato Result::unwrap() su un valore Err

Altro impatto durante l'incidente

Altri sistemi che si basano sul nostro proxy principale sono stati colpiti durante l'incidente. Tra questi, Workers KV e Cloudflare Access. Il team è riuscito a ridurre l'impatto su questi sistemi alle 13:04, quando è stata applicata una patch a Workers KV per aggirare il proxy principale. Successivamente, tutti i sistemi a valle basati su Workers KV (come Access stesso) hanno osservato una riduzione del tasso di errore. 

Anche la dashboard di Cloudflare ha subito un impatto a causa dell'utilizzo interno di Workers KV e della distribuzione di Cloudflare Turnstile come parte del nostro flusso di accesso.

Turnstile è stato interessato da questa interruzione, pertanto i clienti senza una sessione attiva nella dashboard non sono stati in grado di accedere. Ciò si è manifestato come una ridotta disponibilità in due fasce orarie: dalle 11:30 alle 13:10 e tra le 14:40 e le 15:30, come si evince dal grafico sottostante.

Il primo periodo, dalle 11:30 alle 13:10, è stato causato da un impatto su Workers KV, da cui dipendono alcune funzioni del piano di controllo e della dashboard. Questo è stato ripristinato alle 13:10, quando Workers KV ha aggirato il sistema proxy principale.

Il secondo impatto sulla dashboard si è verificato dopo il ripristino dei dati di configurazione delle funzionalità. Un accumulo di tentativi di accesso ha iniziato a sovraccaricare la dashboard. Questo backlog, in combinazione con i tentativi di ripetizione, ha comportato una latenza elevata, riducendo la disponibilità della dashboard. Il ripristino della scalabilità della concorrenza del piano di controllo ha ristabilito la disponibilità alle 15:30 circa.

Passaggi di correzione e follow-up

Ora che i nostri sistemi sono tornati online e funzionano normalmente, abbiamo già iniziato a lavorare su come proteggerli da guasti simili in futuro. In particolare, stiamo:

• Rafforzando l'importazione di file di configurazione generati da Cloudflare nello stesso modo in cui faremmo per gli input generati dagli utenti
• Abilitando ulteriori kill switch globali per le funzionalità
• Eliminando la possibilità che i core dump o altri report di errore sovraccarichino le risorse di sistema
• Revisionando le modalità di errore per condizioni di errore in tutti i moduli proxy principali

Oggi si è verificata la peggiore interruzione di Cloudflare dal 2019. Abbiamo avuto interruzioni che hanno reso indisponibile la nostra dashboard. Interruzioni che hanno causato la mancata disponibilità di funzionalità più recenti per un certo periodo di tempo. Negli ultimi sei anni e più, non abbiamo avuto un altro disservizio che abbia causato l'interruzione del flusso della maggior parte del traffico principale attraverso la nostra rete.

Un'interruzione come quella di oggi è inaccettabile. Abbiamo progettato i nostri sistemi per essere altamente resilienti ai guasti, al fine di garantire che il traffico continui a fluire senza interruzioni. In passato, le interruzioni ci hanno sempre spinto a creare sistemi nuovi e più resilienti.

A nome di tutto il team di Cloudflare, desidero porgere le nostre scuse per il disagio che abbiamo causato oggi a Internet.