All’alba del 2 luglio 2020, nei data center che circondano il pianeta come costellazioni artificiali, qualcosa comincia a vibrare.

È un’impennata improvvisa, assurda, verticale del consumo CPU: migliaia di core che passano da sonnolenti a incandescenti, come se qualcuno avesse acceso un fornello sotto l’intera infrastruttura.

Web server, reverse proxy, firewall applicativi: tutti cadono simultaneamente in apnea.

Pochi minuti dopo, siti in ogni angolo del mondo — grandi e piccoli, innocenti e monumentali — iniziano a sparire dalla rete. Il web si affloscia, come se un filo invisibile fosse stato spezzato.

Il colpevole non è un attacco DDoS, né un worm, un pattern di testo di poche decine di caratteri: una regex.

Un’espressione regolare che, messa in produzione senza sapere cosa poteva evocare, provocò la forma più crudele di rallentamento: il catastrophic backtracking, l’effetto combinatorio che trasforma un match in una spirale infinita.

Così, in quel mattino di luglio, Internet conobbe il potere distruttivo di punto, parentesi ed asterisco.

BUG ARCHEOLOGY – EPISODIO 25

«Un sistema complesso che funziona è sempre evoluto da un sistema semplice che funzionava.»
— John Gall, Systemantics, 1975)

👶 Introduzione per chi parte da zero

Cloudflare è uno dei più grandi custodi dell’infrastruttura web globale.
Accelera contenuti, difende siti, filtra traffico malevolo. Sta nel mezzo: tra te e il sito che visiti, tra un attacco e la sua vittima, tra un pacchetto e il suo destino.

Milioni di pagine appoggiano su di lui la loro sopravvivenza.

Nell’estate del 2020, una semplice configurazione interna aggiorna il motore di rules che filtra il traffico sospetto.

È una routine quotidiana, quasi banale: si testano pattern, si aggiornano condizioni, si sincronizzano migliaia di nodi. Tra questi pattern ci sono le regex, o espressioni regolari: schemi composti da simboli speciali — parentesi, asterischi, più e meno — che dicono al computer quali sequenze di testo cercare. Una regex ben scritta è come una lente magica, capace di trovare ovunque ciò che descrive. Se viene, però, scritta male, può trasformare una semplice ricerca in un labirinto infinito, intrappolando CPU e server.

Quel giorno una delle espressioni regolari introdotte portava con sé un difetto di forma: una combinazione di quantificatori annidati, parentesi ambigue e alternanze profonde.

Una struttura fragile, apparentemente innocua, ma capace di scatenare un comportamento devastante in presenza dell’input giusto.

E l’input giusto — anzi, quello sbagliato — arriva immediatamente.

I. Il sintomo: CPU che urlano

Ore 13:42 UTC.
I grafici interni di Cloudflare iniziano a disegnare ramp-up impossibili: il consumo CPU cresce come un incendio.

Ogni richiesta HTTP che passa per il sistema attiva la regex incriminata, ed ogni match impiega — invece che microsecondi — decine, poi centinaia, poi migliaia di millisecondi.

Non c’è più throughput, né più margine: ogni server è intrappolato in un loop di tentativi di match, incapace di liberarsi.

Il risultato è una caduta sincronizzata dei servizi in decine di regioni: un blackout globale di 27 lunghissimi minuti.

Internet, per un attimo, sembra cedere sotto il peso di un carattere sbagliato.

II. L’origine: la violenza silenziosa di una regex sbagliata

Le espressioni regolari sono uno degli strumenti più antichi e più truccati dell’informatica.
Sono potenti, ma soprattutto sono insidiose.

La regex introdotta nel sistema Cloudflare aveva una forma concettualmente simile a:

(a+)+$

o, più precisamente, a una struttura con:

• quantificatori annidati
• gruppi di cattura multipli
• alternanze non ottimizzate
• potenziali ambiguità di percorso

Un pattern del genere, applicato a stringhe lunghe composte da caratteri ripetuti, può innescare un’esplosione combinatoria: il motore regex cerca tutte le possibili suddivisioni del testo prima di arrendersi.

È un comportamento previsto — perché è così che funziona il backtracking — ma è anche ciò che rende le regex un’arma a doppio taglio.

Una sola stringa può costare milioni di operazioni.

III. Il bug tecnico: il catastrophic backtracking

Il catastrophic backtracking è un fenomeno in cui una regex apparentemente innocua scatena una ricerca infinita.

Per capire il cuore dell’errore, ecco una rappresentazione concettuale:

import re
pattern = re.compile(r"(a+)+$")

# Input innocuo ma pessimo per il pattern
text = "aaaaaaaaaaaaaaaaaaaaaaaaaaaaab"

pattern.match(text)  # attende per tempi enormi

Il motore tenta di matchare:

• tutte le possibili divisioni del gruppo a+
• per ogni divisione, rientra nella ricorsione del gruppo esterno
• e quando scopre che la stringa finisce con una “b”, fallisce
• …riavviando il backtracking a un livello più profondo.

Il risultato è una valanga algoritmica: una sorta diesplosione esponenziale in un sistema che deve rispondere in millisecondi.

Cloudflare amplificò questo effetto perché:

• la regex veniva eseguita su ogni richiesta,
• su milioni di richieste al secondo,
• su sistemi distribuiti che replicano la configurazione simultaneamente.

E così il backtracking bloccò i server stessi.

IV. Il contesto: un aggiornamento di routine, non di guerra

Tutto questo proveniva da un update ordinario delle “WAF rules” — le regole di filtraggio applicativo.

Quell’aggiornamento attivò la regex malformata su tutte le edge location.

Un istante prima tutto funzionava e poco dopo l’intera rete Cloudflare era in ginocchio.

È questo il lato perverso dei sistemi centrali: una singola configurazione, propagata ovunque, è potente quanto fragile.

V. La scoperta: un incidente che parla in caratteri speciali

Gli ingegneri di Cloudflare, nel post-mortem, raccontarono il momento della diagnosi: un log, un pattern in evidenza, un match che non finiva mai.

La regex incriminata si trovava all’interno di un filtro che avrebbe dovuto individuare richieste malevole.
Il suo intento era semplice e sensato. La sua implementazione un tantino meno.

La firma dell’errore fu chiarissima:

• spike CPU sincronizzati,
• latenza infinita nelle funzioni di matching,
• blocchi del processo WAF,
• mancata risposta di Nginx.

In pochi minuti si risalì al problema, in altrettanto poco venne rimossa ed il mondo tornò online.

VI. Implicazioni morali e legali

Questo incidente non uccise nessuno, né distrusse infrastrutture fisiche.
Eppure, per 27 minuti, fece capire quanto sia sottile la membrana che separa il web dalla sua assenza.

Chi era responsabile?
Chi aveva controllato?
Chi avrebbe dovuto prevederlo?

La risposta ufficiale fu la più onesta e la più dolorosa:

“È stato un errore umano, reso critico dalla natura globale del sistema.”

Gli errori nelle regex non sono rari.
Lo è il fatto che un singolo errore possa influenzare l’infrastruttura di mezzo pianeta.

VII. I danni: quando Internet si ferma

Durante quei 27 minuti, sparirono:

• siti governativi
• piattaforme social
• e-commerce
• testate giornalistiche
• servizi bancari
• sistemi di login
• blog personali, compresi quelli senza colpa

Il blackout non fu totale, ma fu onnidirezionale, disinvolto ed indiscriminato.

Come se Internet avesse trattenuto un lungo respiro.

VIII. Contromisure: disinnescare il mostro combinatorio

Dopo l’incidente, Cloudflare introdusse misure profonde.

Tecniche:

• prevenzione automatizzata per pattern “pericolosi”
• limiti di backtracking
• engine regex più resilienti
• timeout duri per match sospetti

Organizzative:

• code review dedicate per espressioni regolari
• test sintetici di carico su pattern complessi
• procedure di rollout con “blast radius” limitato
• allarmi più sensibili alla crescita anomala del CPU time

La lezione tecnica fu semplice: le regex devono essere trattate come codice, non come testo.

IX. Lezioni filosofiche: il potere del minimo

Il bug del 2 luglio 2020 racconta qualcosa di inquietante e bellissimo: che il software moderno è talmente potente da poter essere distrutto da ciò che è minuscolo come una parentesi, un quantificatore, un simbolo speciale.

Tre idee chiave:

1. La complessità non cresce solo aggiungendo, ma anche combinando.
2. Le astrazioni più familiari sono quelle che ci tradiscono di più.
3. Ogni sistema critico è vulnerabile alla sua più piccola unità.

La regex non fece nulla di “sbagliato”: fece esattamente ciò per cui era stata progettata.

X. Epilogo: archeologia di un asterisco

Scavare in questo bug significa vedere il codice non come logica, ma come geologia: strati su strati di funzioni, librerie, idee, pattern.

In un punto, a una certa profondità, si trova quella sequenza di caratteri.
Un frammento di testo che, nel contesto sbagliato, ha la potenza di un ordigno.

Come nei grandi disastri software — Ariane 5, Therac-25, Patriot — il nemico non è ciò che appare immenso, ma ciò che è troppo piccolo per essere notato.

È lì che nasce la catastrofe ed è lì che l’archeologo del bug deve guardare.

XI. Coda: il ritorno del backtracking

Oggi lo stesso rischio vive:

• nei motori di ricerca
• nei router applicativi
• nei linguaggi serverless
• nei sistemi di sicurezza basati su pattern
• negli input utente non sanitizzati

Ovunque una regex si accenda, silente si aggira il fantasma del catastrophe.

Le regex non sono un linguaggio di pattern: sono un patto con l’ignoto, una promessa di ordine che, se scritta male, può invocare il caos.

“Ogni carattere è un universo potenziale.
Ogni universo, se combinato male, può collassare.”

E così, quel giorno di luglio, il web collassò davvero a causa di un semplice carattere che chiedeva troppa attenzione.

📚 Consigli di lettura — per chi vuole capire davvero bug, complessità e sistemi fragili

Se vuoi esplorare più a fondo la fragilità del software, la complessità nascosta e il potere distruttivo dei dettagli minimi, ho raccolto alcuni libri che considero imprescindibili. Se acquisti tramite i link Amazon qui sotto, il blog riceverà una piccola commissione senza costi aggiuntivi per te — grazie per il supporto!

1. Clean Code — Robert C. Martin

Un classico sul pensiero rigoroso nella scrittura del software.
Perfetto per comprendere perché “il dettaglio minimo” non è mai davvero minimo.

2. Il Pragmatic Programmer — Andrew Hunt, David Thomas

Un testo cult che insegna come ragionare sul codice, sugli errori e sui sistemi in evoluzione.
Un ottimo ponte tra pratica quotidiana e principi ingegneristici.

3. Beautiful Code — Andy Oram, Greg Wilson (solo in inglese)

Una raccolta di saggi in cui alcuni dei migliori ingegneri del mondo mostrano che la complessità può essere addomesticata — e anche quando non lo è.

4. Designing Data-Intensive Applications — Martin Kleppmann (solo in inglese)

Per capire come un singolo punto fragile può propagarsi attraverso un sistema distribuito globale.
Un libro amatissimo da chi lavora con infrastrutture come Cloudflare.

5. Software Engineering at Google — Titus Winters, Tom Manshreck, Hyrum Wright (solo in inglese)

Una prospettiva reale su cosa significa mantenere software complesso su scala planetaria: rollback, incidenti, errori umani, mitigazioni.
Molto a tema con il caso del WAF e della regex.

6. Regular Expressions Cookbook — Jan Goyvaerts, Steven Levithan (solo in inglese)

Se vuoi capire davvero cosa fa una regex sotto il cofano, perché alcune esplodono e come evitarlo.
La risorsa più chiara e completa sul tema.