Si chiama HTTP/2 Bomb ed è una tecnica di denial-of-service che, secondo i ricercatori, può compromettere la disponibilità di un server in tempi estremamente rapidi partendo da una sola macchina connessa a una linea domestica, trasformando così un singolo client in una leva sufficiente per mettere sotto pressione sistemi esposti su HTTP/2.

La scoperta è stata attribuita al software agent Codex di OpenAI, operante sotto la supervisione dei ricercatori della società di offensive security Calif. Dal punto di vista tecnico, l’idea alla base di HTTP/2 Bomb non nasce da un elemento completamente inedito, ma la sua novità consiste nell’aver accorpato due debolezze già note all’interno di una sequenza operativa particolarmente aggressiva. Da una parte c’è l’amplificazione della memoria legata a HPACK, il sistema di compressione delle intestazioni previsto da HTTP/2. Dall’altra entra in gioco un comportamento che ricorda Slowloris adattato però al controllo di flusso del protocollo, con l’obiettivo di trattenere le risorse allocate il più a lungo possibile.

Per capire la portata del problema, bisogna soffermarsi sul primo passaggio. HPACK è stato progettato per ridurre l’overhead delle intestazioni HTTP, migliorando efficienza e latenza. In questo contesto, un attaccante può inserire un header nella tabella dinamica e poi richiamarlo ripetutamente tramite una rappresentazione indicizzata estremamente compatta, in alcuni casi grande appena un byte.

Il server, però, non lavora su quel singolo byte, ma deve ricostruire internamente le strutture associate, con un costo in memoria molto più elevato. È qui che nasce l’effetto moltiplicatore. Nei test riportati da Calif, Envoy e Apache httpd hanno mostrato i rapporti peggiori, arrivando rispettivamente a circa 5700:1 e 4000:1 tra dati inviati dall’attaccante e memoria impegnata lato server.

Questo però, da solo, non basterebbe a spiegare l’efficacia distruttiva di HTTP/2 Bomb. La seconda fase è quella che trasforma un abuso di allocazione in una vera crisi operativa. L’attaccante pubblicizza una finestra di flow control pari a zero byte, impedendo di fatto il normale avanzamento della risposta. Il server resta così intrappolato in una sorta di limbo; per evitare timeout, continua infatti a inviare piccoli frame WINDOW_UPDATE, ma le richieste non si chiudono mai davvero e la memoria riservata rimane occupata. In pratica, il sistema continua ad accumulare strutture interne senza riuscire a liberarle con il ritmo necessario, con il risultato di un “soffocamento” progressivo che colpisce il cuore della gestione delle risorse.

HTTP/2 Bomb

Secondo i ricercatori, proprio questa combinazione consente di aggirare difese che, sulla carta, dovrebbero mitigare attacchi basati sugli header. I limiti sulla dimensione complessiva delle intestazioni decodificate, infatti, non intervengono in modo efficace perché i valori trasmessi possono restare molto piccoli. L’impatto reale deriva dal bookkeeping interno, dal numero di header gestiti e dalle allocazioni necessarie a mantenerli in memoria. In altre parole, il collo di bottiglia non è la grandezza apparente del traffico, ma il costo nascosto che quel traffico induce all’interno del server.

I numeri emersi dai test aiutano a contestualizzare la gravità del quadro. Envoy 1.37.2 è arrivato all’esaurimento di 32 GB di RAM in circa dieci secondi, mentre Apache httpd 2.4.67 ha raggiunto lo stesso risultato in circa diciotto secondi. NGINX 1.29.7 e IIS su Windows Server 2025 hanno mostrato una resistenza maggiore, ma comunque insufficiente a rassicurare. Sono tempi brevissimi per qualsiasi ambiente produttivo esposto direttamente su Internet, soprattutto in scenari dove il monitoraggio non è calibrato per individuare un consumo anomalo di memoria con crescita così rapida.

La lista dei software coinvolti rende la questione ancora più delicata. Le configurazioni predefinite di diversi server diffusi risultano esposte, inclusi NGINX, Apache HTTP Server, Microsoft IIS, Envoy e Cloudflare Pingora. Va detto, però, che il rischio effettivo cambia molto in base all’architettura. Le installazioni protette da CDN, reverse proxy o firewall applicativi possono ridurre sensibilmente la superficie d’attacco, perché l’endpoint HTTP/2 vulnerabile non è direttamente raggiungibile o perché esistono limiti aggiuntivi sul numero di header. Anche alcune configurazioni personalizzate possono offrire una protezione indiretta, così come la disattivazione di HTTP/2 nei contesti in cui il protocollo non è strettamente indispensabile.

Sul fronte delle correzioni qualcosa si è già mosso, ma il quadro resta incompleto. NGINX ha risolto il problema con la versione 1.29.8 introducendo la direttiva max_headers, mentre Apache ha corretto la vulnerabilità in mod_http2 2.0.41, associandole l’identificativo CVE-2026-49975. Al momento in cui la vicenda è stata resa pubblica, invece, non risultavano ancora patch per IIS, Envoy e Pingora. In questi casi, la raccomandazione più pragmatica consiste nel disabilitare HTTP/2 dove possibile, oppure nel collocare davanti al server un proxy o un firewall capace di imporre limiti rigidi sul numero di header accettati per richiesta.

Un altro elemento da non sottovalutare riguarda la tempistica della divulgazione. I dettagli completi dell’attacco saranno presentati alla conferenza Real World AI Security nel corso del mese in un intervento del ricercatore Quang Luong. Tuttaviam i proof of concept sono già disponibili pubblicamente su GitHub e ciò significa che la finestra tra disclosure tecnica e sfruttamento concreto rischia di essere molto stretta. Per chi gestisce infrastrutture web, il margine di attesa è quindi ridotto e si consiglia quindi di verificare le versioni in uso, controllare l’esposizione diretta dei servizi HTTP/2 e introdurre limiti più severi sulla gestione degli header.

(Immagine in apertura: Shutterstock)