Disservizio 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 "feature file" utilizzato dal nostro sistema di Bot Management. Tale feature file, a sua volta, è raddoppiato in dimensioni. Il feature file, 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 feature file per mantenere aggiornato il nostro sistema Bot Management con le minacce in continua evoluzione. Il software aveva un limite di dimensione del feature file 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 feature file 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 disservizio 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 disservizio come questo non si verifichi più.

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

Il volume precedente alle 11:20 è il livello normale atteso di errori 5xx osservati nella nostra piattaforma. Il picco e le successive fluttuazioni mostrano un errore del sistema causato dal caricamento di un feature file non corretto. È interessante notare che il nostro sistema si sarebbe poi ripreso per un certo periodo. Questo è stato un comportamento molto insolito per questo tipo di malfunzionamento.

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 feature file non valido e inserendo manualmente un file valido noto nella coda di distribuzione dei feature file. 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 disservizio 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 Observability, che migliorano automaticamente il processo di rilevamento degli errori non precedentemente rilevati tramite informazioni di debug aggiuntive.

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, vengono eseguiti i prodotti di sicurezza e performance messi a disposizione dalla nostra piattaforma. 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. Tutto ciò attraverso una serie di moduli specifici per ciascun dominio che applicano le regole e i criteri di configurazione al traffico in transito nel nostro proxy.

Uno di questi moduli, Bot Management, è stata la causa del disservizio odierno. 

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 o meno ai loro siti.

Il modello accetta come input un feature file di configurazione. In questo contesto, una feature è un tratto individuale utilizzato dal modello di machine learning per prevedere se la richiesta è stata automatizzata o meno. Tutte queste caratteristiche fanno parte del del feature file di configurazione.

Questo file viene aggiornato con una cadenza di pochi minuti, pubblicato sull'intera nostra rete e ci consente di reagire alle variazioni dei flussi di traffico a nuovi tipi di bot e a nuovi attacchi degli stessi. È 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 elevato numero di righe di "feature" duplicate. Questo ha modificato la dimensione del file, precedentemente di dimensioni fisse, causando l'attivazione di un errore da parte del modulo Bot Management.

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 da questo modulo. Ciò ha interessato anche Workers KV e Access, che si basano sul proxy principale.

Indipendentemente da questo incidente, stavamo 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 serviti dal nuovo proxy FL2 hanno riscontrato errori HTTP 5xx. I clienti che invece utilizzavano il nostro 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 (ovvero attribuibile a richieste automatizzate). 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 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 della nostra infrastruttura, senza alcuna dipendenza da Cloudflare. Sebbene questa si sia rivelata una coincidenza, ciò ha indotto alcuni membri del team impegnati nel troubleshooting a ritenere che un utente malintenzionato potesse aver preso di mira sia i nostri sistemi sia la nostra pagina di servizio. I visitatori della pagina 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:

Come menzionato in precedenza, una modifica nel comportamento della query sottostante ha fatto sì che il feature file 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 Distributed) in un database chiamato default. Il motore distribuito interroga le tabelle sottostanti in un database r0. Tali tabelle 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 default quando interrogavano i metadati alle tabelle dalle tabelle di sistema ClickHouse come system.tables o system.columns.

Poiché gli utenti hanno già un accesso implicito alle tabelle sottostanti 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 "default":

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 feature file di Bot Management per creare le funzionalità di input per il file summenzionato. 

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 feature) nell'output del file finale. 

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 feature 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 feature. È bene ribadire che il limite esiste perché, per motivi di prestazioni, preallochiamo memoria per le feature.

Quando il file danneggiato con più di 200 feature è 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

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 questo disservizio, 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 feature. 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à del piano di controllo ha ristabilito la disponibilità alle 15:30 circa.

Non appena i nostri sistemi sono tornati online e a funzionare normalmente, abbiamo 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 feature

• Eliminando la possibilità che i core dump o altri report di errore sovraccarichino le risorse di sistema

• Revisionando le procedure di gestione degli errori in tutti i moduli proxy principali

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

Ciò che è accaduto 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, i disservizi 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.