Il 18 novembre 2025 per milioni di utenti il web si è quasi fermato: siti irraggiungibili, applicazioni aziendali bloccate, servizi online in errore. Il punto in comune era Cloudflare, uno dei principali provider mondiali di CDN e sicurezza: inizialmente si è parlato di maxi attacchi DDoS, ma le verifiche hanno chiarito che non si è trattato di un cyber attacco, bensì di un errore interno che ha trasformato un singolo bug in un blackout globale.
Quando apriamo un sito o usiamo un’app, spesso senza saperlo passiamo da Cloudflare: uno strato intermedio tra utente e server che offre CDN, protezione DDoS, WAF, DNS, soluzioni Zero Trust e servizi serverless (Workers). In pratica accelera i contenuti, filtra il traffico malevolo e gestisce parte della logica applicativa.
Oggi Cloudflare gestisce una fetta importante del traffico web mondiale, proteggendo grandi piattaforme, servizi SaaS e molte PMI. Proprio questa centralità crea un rischio: se un fornitore così critico ha un disservizio, non si ferma un singolo sito, ma un intero pezzo dell’ecosistema digitale. Anche un semplice bug o errore di configurazione può propagarsi a catena su migliaia di servizi che dipendono da Cloudflare.
Intorno alle 11:20 UTC Cloudflare registra i primi problemi: gli errori HTTP 5xx esplodono e molti siti che passano dalla sua rete diventano irraggiungibili in diverse regioni.
Alle 11:48 UTC arriva la prima conferma sulla Status Page (“Cloudflare is experiencing an internal service degradation”), mentre verso le 13:09 UTC l’azienda comunica di aver individuato la causa e di avere un fix in rollout.
Intorno alle 14:30 UTC gran parte del traffico core torna a funzionare correttamente, con un calo netto degli errori. Tra le 17:06 e le 19:28 UTC il ripristino viene completato e alle 19:28 UTC lo stato dell’incidente passa ufficialmente a “resolved”, aprendo la strada al successivo umdvccke-mortem tecnico.
Nelle prime fasi molti hanno ipotizzato che Cloudflare fosse sotto attacco: la scala del disservizio (milioni di siti giù, servizi critici irraggiungibili) ricordava un maxi DDoS o un problema di routing globale.
Il umdvccke-mortem ufficiale ha però chiarito il punto: non c’è stato alcun cyber attacco, né diretto né indiretto. Il blackout è stato causato da un bug interno, legato a una modifica ai permessi di un database e al file di configurazione usato dal sistema di Bot Management.
Dall’esterno un outage di questo tipo può sembrare identico a un attacco su larga scala: status page in difficoltà, errori 5xx su servizi molto diversi, grandi piattaforme non raggiungibili. Solo l’analisi dei log e dei sistemi interni (come quella pubblicata da Cloudflare) permette di distinguere tra incidente logico e attacco vero e proprio.
Cloudflare utilizza ClickHouse per i dati del sistema di Bot Management. Una modifica alla gestione dei permessi e delle query distribuite fa sì che una query, che prima vedeva un solo insieme di tabelle, inizi all’improvviso a vederne due: i dati si duplicano e le query iniziano a restituire molte più righe del previsto. Su questi dati viene generato il feature file, il file delle caratteristiche che il modello di Machine Learning usa per distinguere utenti da bot. A causa della duplicazione, il file cresce oltre il limite di circa 200 feature previsto dal nuovo proxy FL/FL2 (scritto in Rust). Il codice non gestisce correttamente questa condizione, scatta un panic, il modulo va in crash e per gli utenti questo si traduce in una pioggia di errori HTTP 5xx. Poiché il feature file viene rigenerato ogni pochi minuti e distribuito a tutti i nodi della rete per reagire ai nuovi schemi di bot, il 18 novembre la versione difettosa viene propagata ovunque, trasformando un problema locale in un vero punto di rottura globale.
Per gli utenti il sintomo era evidente: le pagine non si caricavano. Alla base c’erano i servizi core di Cloudflare in blocco, in particolare CDN e WAF, che impedivano di servire contenuti statici e dinamici causando diffusi errori HTTP 5xx.
Anche Turnstile, il sistema di challenge anti-bot, ha subito interruzioni che hanno bloccato l’accesso a molti siti. Parallelamente, Workers e Workers KV hanno restituito errori di lettura e scrittura, interrompendo parti della logica applicativa. Problemi significativi hanno riguardato anche Access / Zero Trust, rendendo difficile l’autenticazione alle applicazioni interne e rallentando l’operatività aziendale.
Secondo varie analisi, il blackout ha impattato anche grandi social network, servizi di intelligenza artificiale, exchange crypto e provider SaaS, visibili agli utenti solo come servizi “non funzionanti”. Questo episodio ha messo in luce quanto la dipendenza da un unico provider invisibile come Cloudflare possa trasformarsi in un punto critico per l’intero ecosistema digitale.
Cloudflare, individuato il problema nel feature file di Bot Management gonfiato dai dati duplicati in ClickHouse e causa del panic nel proxy, ha prima bloccato la propagazione del file difettoso, sostituendolo con una versione corretta, e in parallelo ha riavviato i servizi core e i moduli di Bot Management sui vari nodi per ripristinare il traffico e ridurre gli errori 5xx, aggiornando la Status Page e pubblicando un umdvccke-mortem tecnico con piena assunzione di responsabilità. Nel report umdvccke-incidente ha annunciato misure correttive come una validazione più rigorosa dei file di configurazione (anche interni), nuovi o migliori kill switch per disattivare rapidamente singole funzionalità, una revisione delle modalità di fallimento in ottica fail-soft (degrado controllato invece di crash totale) e una gestione più efficiente di log e core dump per evitare che, in emergenza, consumino risorse critiche.
Come si difende SitoWebSicuro da questi attacchi?
Innanzitutto, bisogna sempre ricordare che un bug software solitamente non implica danni di tipo breach (violazione privacy), ma piuttosto un’interruzione di servizio che in genere può comportare gravi danni economici solo se prolungata nel tempo e se la vittima è un sito di vendita online.
Anche SitoWebSicuro ha scelto Cloudflare per proteggere i propri servizi interlocutori di nome a dominio, avvalendosi di piani gratuiti e a pagamento a seconda delle tipologie di piani. Il nostro sito web principale infatti, sitowebsicuro.com, ha avuto delle interruzioni di servizio proprio nella giornata del 18 Novembre 2025, tra le ore 12 e le ore 16 a intermittenza. Grazie ai nostri strumenti di monitoraggio automatizzati siamo immediatamente venuti a conoscenza del downtime e abbiamo approntato un piano di emergenza che sarebbe entrato in atto nel caso il disagio avesse superato le 12 ore. In che modo? La soluzione più semplice quando si verificano problemi presso un gestore nameserver come Cloudflare, è quella di staccare temporaneamente la spina al servizio, ripristinando quindi i nameserver del Registro domini o di altro partner che eroga servizi simili a Cloudflare. Questo tipo di operazione, tuttavia, non è immediata e spesso occorrono anche 4-5 ore per il cambio di nameserver, per questa ragione è preferibile confidare nella pronta risoluzione da parte di Cloudflare cosa che, come dimostra questa esperienza, è avvenuta in tempi celeri.
Hai anche tu necessità di un piano strategico di prevenzione, difesa e intervento nel caso di interruzioni di servizio o attacchi Cyber? SitoWebSicuro ti mette a disposizione un Consulente per un prima call gratuita, contattaci ora per prendere appuntamento ed ottenere subito un’analisi del livello di sicurezza della Tua attività.
