Il giorno 18 novembre 2025 alle 11:20 UTC (tutti gli orari indicati in questo articolo sono UTC), la rete globale di Cloudflare ha cominciato a riscontrare gravi problemi nella consegna del traffico core. Gli utenti che cercavano di accedere ai siti dei clienti Cloudflare venivano accolti da una pagina di errore, segnalante un malfunzionamento interno alla rete.

Cosa è successo

L’incidente non è stato causato da un attacco informatico né da attività malevole. La radice del problema è stata una modifica ai permessi su uno dei sistemi database della società, che ha innescato un effetto a catena: quel cambiamento ha generato duplicazioni massicce di righe in un file di configurazione (“feature file”) utilizzato dal sistema di Bot Management. Questo file di configurazione è poi stato propagato su tutte le macchine della rete Cloudflare, ed è diventato più grande del previsto. Il software interno che legge quel file aveva un limite di dimensione, e quel limite è stato superato — portando al malfunzionamento del sistema.

Effetti rilevati

Le macchine del proxy core (chiamate “Frontline” o “FL/FL2” internamente) sono entrate in uno stato di errore: in particolare, i codici HTTP 5xx hanno cominciato a salire drasticamente. Il pattern osservato era strano: dopo l’inizio dell’errore, il sistema talvolta recuperava e poi ricadeva nello stato di errore, finché non tutti i nodi del database hanno generato il file errato.

Alcune infrastrutture collegate sono state impattate:

• I servizi CDN e di sicurezza principali della rete Cloudflare.
• Il servizio Turnstile (sistema di verifica bot/human) non riusciva a caricarsi.
• Il servizio Workers KV ha restituito un alto numero di errori 5xx, perché il gateway interno (“front-end”) era fallito a causa del proxy core in problemi.
• Il servizio Access ha avuto problemi di autenticazione: dal momento dell’incidente, molti utenti non riuscivano a raggiungere l’applicazione target perché l’autenticazione non veniva completata correttamente.
• Anche la latenza della CDN è aumentata, a causa del carico elevato sulla CPU dei sistemi di debug/observability, che automaticamente arricchiscono gli errori non intercettati con informazioni di debug.

Perché è avvenuto

Il sistema di Bot Management utilizza un file di configurazione (“feature file”) che contiene decine di “feature” — ovvero attributi usati dall’algoritmo di machine learning per valutare se una richiesta è automatica (bot) oppure umana. Quel file viene generato ogni pochi minuti e pubblicato in tutta la rete, per adattarsi rapidamente alle evoluzioni del traffico internet. Il database utilizzato è ClickHouse, che comprende una serie di shard e tabelle distribuite. Un cambiamento nelle autorizzazioni alle query ha fatto sì che venissero incluse righe duplicate da tabelle sottostanti (“r0” database) che prima non venivano viste. Di conseguenza, il numero di “feature” nel file è più che raddoppiato — superando il limite prestabilito (il sistema era preallocato per usare fino a circa 200 feature, quando il numero reale era intorno a ~60) — e tale causa ha generato un errore non controllato (“panic”) nel codice Rust del proxy “FL2”.

Timeline dell’incidente (UTC)

• Alle 11:05: modifica ai permessi del database distribuito ClickHouse.
• Alle 11:28 circa: inizio dell’impatto, con errori HTTP 5xx osservati.
• Alle 13:05: è stato messo in atto un bypass per Workers KV e Access, riducendo parte dell’impatto.
• Alle 14:24: è stato interrotto il processo di generazione e propagazione del file di configurazione errato per Bot Management.
• Alle 14:30: l’impatto principale è stato risolto, ed è stato distribuito globalmente un file corretto.
• Alle 17:06: tutti i sistemi sono completamente tornati alla normalità.

Cosa farà Cloudflare per evitare un nuovo incidente

Secondo quanto spiegato nella comunicazione ufficiale, Cloudflare ha già avviato una serie di azioni correttive e preventive:

• Rinforzare (“hardening”) l’ingestione dei file di configurazione generati da Cloudflare con lo stesso livello di attenzione riservato all’input generato dagli utenti.
• Abilitare interruttori globali (kill switches) per le funzionalità, in modo da poter spegnere rapidamente una parte problematica del modulo se necessario.
• Eliminare la possibilità che core dump o rapporti di errore possano saturare risorse di sistema.
• Revisionare tutti i “failure mode” (modi di fallimento) per tutte le componenti del proxy core.
• Riconoscere che questo è stato l’incidente più grave di Cloudflare dal 2019: avevano avuto outage che hanno reso indisponibile la dashboard o alcune funzionalità, ma non avevano mai bloccato la maggior parte del traffico core nella rete nei sei anni precedenti.

Quali sono le lezioni per noi (IT, DevOps, NetOps)

Se sei un responsabile infrastrutture, un team DevOps o NetOps, l’outage del 18 novembre 2025 di Cloudflare porta alcune lezioni importanti:

• Anche i grandi player con architetture globali distribuite possono incorrere in problemi dovuti a modifiche “apparentemente innocue” alle autorizzazioni o alle query dei database.
• Il fatto che una file di configurazione critica venga propagato automaticamente globalmente rappresenta un punto di vulnerabilità: se una versione errata viene distribuita, l’impatto può essere enorme.
• Il sistema di “feature file” aveva un limite statico/preallocato che non era pensato per più che ~60 feature; quando il numero è salito improvvisamente sopra 200, il sistema non ha gestito l’errore in modo elegante.
• I segnali iniziali (errori 5xx sparsi, latenza elevata) potrebbero far pensare ad un attacco (ad esempio un DDoS). In questo caso, inizialmente Cloudflare ha seguito questa ipotesi.
• La trasparenza nel comunicare l’incidente e i passi successivi è molto importante per la fiducia degli utenti/clienti.
• Operativamente: avere circuit breaker, capacità di rollback rapido, isolamento delle parti critiche e test di “what-if” per scenari di errore sono elementi fondamentali.

Conclusione

Il down del 18 novembre 2025 di Cloudflare ci ricorda che anche infrastrutture molto diffuse e affidabili non sono immuni da incidenti. In questo caso la causa non è stata un attacco esterno, ma un errore interno di configurazione che ha avuto effetto a catena. La prontezza nella diagnosi, la capacità di rollback e le azioni pianificate per evitare recidive sono stati elementi chiave della risposta. Per chi gestisce reti, applicazioni web o infrastrutture cloud, è una lezione utile: controlli, limiti, rollback, e automazione ben governata sono indispensabili.

Altri articoli

Come Difendersi dagli Attacchi DDoS: Strategie Efficaci per la Sicurezza Online

I 10 errori più comuni in Python

Nessuno sa cosa fa davvero un programmatore

Le Basi del Quantum Computing e l’Impatto sulla Cybersecurity