Negli ultimi mesi Cloudflare, uno dei pilastri dell’infrastruttura web globale, ha vissuto una serie di incidenti significativi: un blackout globale il 18 novembre 2025, un guasto allo storage a giugno e problemi legati alla rotazione delle credenziali a marzo. Questi eventi non sono semplici disguidi tecnici: sono campanelli d’allarme per tutte le aziende che poggiano la loro operatività su servizi cloud e CDN.
Cosa è successo?
Sembrerebbe che l’incidente del 18 novembre sia da ricondurre all’applicazione di una modifica ai permessi di un cluster ClickHouse (un componente fondamentale dell’infrastruttura dati che alimenta numerosi servizi interni). L’intervento, pensato per migliorare la gestione e la trasparenza dei permessi sui dati distribuiti, ha però generato un comportamento inatteso: ClickHouse ha cominciato a produrre un numero anomalo di righe duplicate all’interno del “feature file”, il file di configurazione che il sistema di Bot Management rigenera automaticamente ogni pochi minuti e distribuisce rapidamente a tutti i nodi della rete globale.
Il raddoppio improvviso della dimensione del feature file, dovuto ai dati duplicati, ha superato il limite operativo del modulo software incaricato di leggerlo, causando un errore interno che si è propagato in modo immediato. Il core proxy è diventato incapace di gestire correttamente il traffico dipendente da quel file: da lì è partita una cascata di errori 5xx su larga scala, la cui dinamica è stata descritta così: “Questo comportamento ha reso poco chiaro ciò che stava accadendo, dato che l’intero sistema sembrava riprendersi per poi fallire nuovamente”.
A complicare ulteriormente le operazioni, la pagina di status ufficiale di Cloudflare, ospitata su un’infrastruttura esterna, è risultata irraggiungibile nelle stesse ore, fattore che ha inizialmente alimentato sospetti di un possibile attacco e ha disorientato il team impegnato nella diagnosi.
Come si è manifestato il blackout?
Il collasso della rete è diventato evidente quando la configurazione alterata ha raggiunto un numero critico di nodi e la diffusione del feature file difettoso ha semplicemente superato la soglia di tolleranza del software lettore. Il volume di errori 5xx è aumentato in modo coerente con la propagazione del file danneggiato fino a stabilizzarsi nella fase più critica, coinvolgendo simultaneamente gran parte dell’infrastruttura.
L’alternanza iniziale tra file corretti e file errati, effetto del comportamento irregolare del cluster ClickHouse, ha reso la diagnosi più difficile, fino a quando la presenza diffusa del file difettoso non ha rivelato con chiarezza la causa. Le conseguenze si sono manifestate trasversalmente sui servizi: la CDN e i sistemi di sicurezza hanno cominciato a restituire pagine di errore dal core proxy; Turnstile non si caricava; Workers KV ha registrato un aumento delle risposte 5xx; la dashboard era accessibile solo per sessioni già attive; Email Security ha perso accesso a fonti di reputazione IP e alcune automazioni non venivano eseguite; Cloudflare Access ha fallito frequentemente nelle autenticazioni, impedendo l’accesso ad applicazioni protette.
A peggiorare la situazione è stato l’aumento della latenza e il sovraccarico generato dai sistemi di debugging interni, che, cercando di arricchire i log e le segnalazioni diagnostiche, hanno aggiunto carico al sistema nel momento di massimo impatto.
Sequenza di riparazione
La fase decisiva delle operazioni di ripristino è iniziata quando il team tecnico ha potuto isolare con maggiore precisione l’anomalia. Quasi immediatamente sono stati implementati bypass interni per Workers KV e Access: queste contromisure hanno consentito ai servizi di appoggiarsi temporaneamente a versioni precedenti del proxy, riducendo parte dell’impatto su autenticazioni e flussi applicativi. Parallelamente, l’analisi si è concentrata sul comportamento del Bot Management e sulla distribuzione dei feature file ancora in circolazione.
Implicazioni per le imprese
Dipendenza critica: molte applicazioni, API e siti fanno affidamento su servizi come Cloudflare per sicurezza, performance e disponibilità. Un malfunzionamento può tradursi in ricavi persi, danni alla reputazione e perdita di fiducia.
Rischio operativo interno: non serve un attacco esterno per causare una grave interruzione; errori di configurazione, regressioni indotte da change management o dati corrotti possono avere impatti sistemici.
Verifica dei fornitori: questi incidenti evidenziano la necessità di rivedere contratti, SLA e dipendenze da provider esterni; assumere che “il cloud non fallisca mai” è un rischio che non si può più correre.
Resilienza progettuale: servono strategie di fallback reali (multi‑CDN, backup DNS, failover automatico, meccanismi di rollback nelle pipeline) per ridurre il blast radius di un guasto.
Cosa può fare Prisma per proteggere la tua azienda?
Prisma offre un approccio pratico, tecnico e operativo per ridurre esattamente i rischi emersi in questo episodio:
Analisi del rischio infrastrutturale: mappiamo dipendenze e punti singoli di guasto (SPOF) in CDN, DNS, storage, data pipelines e provider esterni.
Progettazione e implementazione di architetture resilienti: multi‑CDN, fallback DNS, caching avanzato, region failover e deploy safe‑guards per limitare la superficie d’impatto.
Hardened configuration e policy di change management: limiti e validazioni per i file di configurazione (ad es. dimensione massima, schemi di validazione), controlli pre‑deploy e roll‑out canary per ridurre il rischio di regressioni.
Gestione sicura delle credenziali e deployment safe‑guards: secret management centralizzato, separazione degli ambienti, rollout graduali e controlli automatici per evitare distribuzioni in ambienti sbagliati.
Monitoraggio proattivo e anomaly detection: alert non solo su downtime ma su pattern (crescita dimensionale anomala di file, spike di duplicati, error‑rate crescente, latenza) con runbook automatici per azioni immediate.
Test di resilienza e tabletop exercises: chaos engineering controllato e esercitazioni pratiche per verificare che team e processi reagiscano correttamente.
Incident response e retainer operativo: supporto on‑demand per gestione incidenti, post‑mortem e implementazione di misure correttive rapide.
Perché agire ora?
Il blackout di Cloudflare dimostra quanto una singola modifica, anche se fatta con le migliori intenzioni, possa avere conseguenze sistemiche quando dati, distribuzione automatica dei file e moduli critici si combinano senza adeguati limiti e salvaguardie. Le aziende non possono più confidare nella sola affidabilità del provider: servono architetture difensive, policy operative e partner con esperienza pratica nella prevenzione e nella gestione degli incidenti.