HTTP/2 Bomb: un solo PC può mandare KO Apache, NGINX e IIS esaurendo 32 GB di RAM in 10 secondi

Una connessione domestica da 100 Mbps, un singolo client e pochi secondi di tempo: bastano questi elementi per mettere fuori servizio alcuni dei server web più diffusi al mondo e, di conseguenza, i siti che ospitano e rendono accessibili. La nuova tecnica DoS (Denial of Service) denominata HTTP/2 Bomb ha subito attirato l’attenzione perché sfrutta caratteristiche previste dal protocollo HTTP/2 senza richiedere botnet, infrastrutture distribuite o grandi quantità di traffico.

Che uno o più siti web, anche a elevato traffico, possano essere resi irraggiungibili da un singolo client remoto è qualcosa che non può non far sobbalzare sulla sedia, rendendo inevitabilmente più calda quella di webmaster, amministratori di sistema e responsabili di rete.

D’altra parte, il protocollo HTTP/2 rappresenta ancora la base di milioni di siti e applicazioni web, dai portali aziendali alle API pubbliche. La ricerca, attribuita ai ricercatori della società Calif con il supporto dell’agente software Codex di OpenAI, mostra come vulnerabilità presenti presumibilmente da anni possano acquisire una pericolosità completamente diversa quando combinate in modo efficace. Le stime diffuse dai ricercatori parlano di centinaia di migliaia di sistemi potenzialmente esposti attraverso configurazioni predefinite dei principali server HTTP.

Perché l’attacco HTTP/2 Bomb riesce a consumare enormi quantità di memoria

La tecnica HTTP/2 Bomb si basa sull’unione di due meccanismi distinti: il primo riguarda HPACK, il sistema di compressione delle intestazioni. Lo scopo originario era ridurre la quantità di dati trasmessi sulla rete eliminando la ripetizione di header identici tra richieste successive.

Gli attaccanti inseriscono valori nella tabella dinamica utilizzata da HPACK e successivamente li richiamano migliaia di volte attraverso rappresentazioni estremamente compatte. In pratica, un singolo byte inviato dal client può costringere il server a effettuare allocazioni di memoria molto più grandi. Nei test pubblicati dai ricercatori, Apache HTTP Server ed Envoy hanno mostrato rapporti di amplificazione superiori rispettivamente a 4.000:1 e 5.700:1.

Da sola, questa tecnica non rappresenterebbe una novità assoluta. Già in passato la comunità della sicurezza aveva analizzato i cosiddetti HPACK Bomb. Le contromisure implementate negli anni, però, si concentrano soprattutto sulla dimensione complessiva degli header decodificati, mentre HTTP/2 Bomb sfrutta un’altra caratteristica del protocollo: lo vediamo al paragrafo seguente.

Il ruolo del flow control e l’effetto Slowloris

La seconda fase dell’attacco riprende il funzionamento storico di Slowloris, una tecnica che mantiene aperte numerose connessioni verso il server per esaurirne progressivamente le risorse e impedirgli di gestire correttamente le richieste legittime.

Dopo aver costretto il server ad allocare memoria, il client impedisce che tale memoria sia liberata utilizzando il sistema di flow control previsto da HTTP/2.

Il client pubblicizza una finestra di ricezione pari a zero byte, comunicando di fatto al server di non essere pronto a ricevere ulteriori dati. Il server continua a mantenere aperta la connessione e invia periodicamente piccoli frame WINDOW_UPDATE per evitare timeout. Le richieste rimangono incomplete e le strutture dati allocate in memoria restano attive molto più a lungo del previsto.

Le specifiche HPACK discutono il rischio di amplificazione della memoria, ma non considerano in modo approfondito uno scenario nel quale l’attaccante riesca anche a trattenere indefinitamente le risorse allocate. La combinazione dei due fattori produce un effetto cumulativo particolarmente aggressivo.

I risultati ottenuti contro Apache, NGINX, IIS ed Envoy

I test pubblicati dai ricercatori mostrano numeri difficili da ignorare. Envoy 1.37.2 ha esaurito 32 GB di RAM in circa 10 secondi; Apache HTTP Server 2.4.67 ha raggiunto lo stesso risultato in circa 18 secondi. NGINX 1.29.7 e Microsoft IIS su Windows Server 2025 hanno richiesto poco meno di un minuto per saturare rispettivamente 32 e 64 GB di memoria.

Molte organizzazioni utilizzano reverse proxy, bilanciatori, firewall applicativi o configurazioni personalizzate che possono ridurre significativamente la superficie d’attacco. Ciò non toglie che il problema colpisca impostazioni predefinite presenti in software estremamente diffusi.

Un altro elemento rilevante riguarda la quantità di banda richiesta. A differenza dei tradizionali attacchi volumetrici, HTTP/2 Bomb non punta a saturare la rete: l’obiettivo è consumare memoria lato server remoto sfruttando un rapporto di amplificazione particolarmente favorevole all’attaccante.

Patch disponibili e sistemi ancora esposti

Le correzioni hanno già iniziato a comparire. NGINX ha risolto il problema nella versione 1.29.8 introducendo la direttiva max_headers, impostata per default a 1000 header per richiesta. Apache ha corretto la vulnerabilità nel modulo mod_http2 2.0.41, associando il problema all’identificativo CVE-2026-49975.

Al momento della divulgazione pubblica non risultano ancora disponibili aggiornamenti ufficiali per Microsoft IIS, Envoy e Cloudflare Pingora. In questi casi gli amministratori devono valutare misure compensative, come la disattivazione temporanea di HTTP/2 o l’introduzione di proxy intermedi capaci di applicare limiti rigidi sul numero di header accettati per singola richiesta.

Alcuni operatori stanno anche adottando limiti di memoria a livello di processo tramite container, cgroups Linux o policy dedicate del sistema operativo. Non è una soluzione definitiva, ma può impedire che un singolo worker esaurisca completamente le risorse della macchina fisica.

Per gli amministratori la priorità consiste nel verificare immediatamente le versioni dei server web in uso, applicare gli aggiornamenti disponibili e riesaminare le impostazioni HTTP/2 esposte verso Internet.