HTTP/2 Bomb consente di crashare Apache HTTP Server in 60 secondi (aggiornato: 19 giugno 2026, ore 09:06)

Un singolo computer domestico con una connessione da 100 Mbps può costringere un server Apache in produzione a consumare circa 32 GB di RAM in 18 secondi e mandarlo offline in meno di un minuto. Niente botnet, niente credenziali, niente complessità particolari. È lo scenario aperto dalla pubblicazione del proof-of-concept per CVE-2026-49975, la vulnerabilità ribattezzata "HTTP/2 Bomb" che colpisce Apache HTTP Server - e non solo lui. Il codice dell'exploit è su GitHub, scritto in Python, gira in un container Docker e, a detta degli esperti di sicurezza, è alla portata di chiunque. Per gli amministratori di sistema che non hanno ancora aggiornato, il tempo utile si è ridotto a zero.

Come funziona la bomba

La vulnerabilità non sfrutta un singolo difetto: concatena due tecniche note del protocollo HTTP/2 trasformandole in un'arma asimmetrica. Il risultato è un attacco DoS che non richiede alcuna autenticazione.

La prima componente è un HPACK compression bomb. HPACK è il meccanismo di compressione degli header in HTTP/2: consente al client di inserire un header nella tabella dinamica e poi referenziarlo migliaia di volte con un puntatore di un singolo byte. Sul cavo viaggia un solo byte, ma sul server ogni riferimento materializza un'allocazione di memoria completa per l'header originale. Il proof-of-concept spinge questa leva fino a 4.091 riferimenti nella tabella HPACK. Nel caso specifico di Apache, il problema è aggravato dal fatto che più campi header cookie vengono uniti internamente senza rispettare la direttiva LimitRequestFields.

La seconda componente è un blocco del controllo di flusso, tecnica che ricorda il vecchio attacco Slowloris ma opera a livello di protocollo HTTP/2. L'attaccante imposta la finestra di controllo di flusso a zero byte: il server ha preparato la risposta, l'ha allocata in memoria, ma non può inviarla e quindi non può liberare le risorse. Per evitare che la connessione vada in timeout, lo script invia periodicamente piccoli frame WINDOW_UPDATE - un singolo byte ogni due secondi, quanto basta per tenere in vita gli stream fino a 300 secondi.

Il proof-of-concept pubblicato dal team EQSTLab su GitHub utilizza appena 10 connessioni con 100 stream ciascuna. Parametri modesti, effetti tutt'altro che modesti. «È facile da eseguire. Dal lato dell'attaccante non servono grandi risorse», ha commentato Pascal Geenens, direttore della threat intelligence di Radware.

Non solo Apache: un problema di protocollo

Il CVE-2026-49975 è assegnato specificamente ad Apache HTTP Server, ma il problema affonda le radici nell'implementazione di HTTP/2 in senso più ampio. Envoy ha ricevuto un CVE separato (CVE-2026-47774) ed è risultato vulnerabile - bastano 10 secondi per esaurirne la memoria. Anche nginx, Microsoft IIS e Cloudflare Pingora figurano tra i software colpiti, benché per nginx non fosse ancora stato assegnato un CVE al momento della stesura.

Le versioni di Apache interessate vanno dalla 2.4.17 alla 2.4.67. Il punteggio CVSS è 7.5, classificato "high-severity". Red Hat ha etichettato la vulnerabilità come "Important" e ha confermato l'impatto diretto su RHEL 8, 9 e 10, oltre che su OpenShift Service Mesh 2 e 3, con potenziali ripercussioni su OpenShift Container Platform, OpenStack Platform e Red Hat Virtualization.

Uno scan Shodan condotto dal team di ricerca di Calif ha identificato oltre 880.000 siti web che supportano HTTP/2 e utilizzano uno dei server vulnerabili. Non si tratta di un problema di nicchia.

Chi l'ha trovata e come

La vulnerabilità è stata scoperta dal ricercatore di sicurezza Quang Luong del team Calif, che ha utilizzato l'agente AI Codex di OpenAI come strumento di analisi.

» Leggi: OpenAI lancia Daybreak: GPT-5.5 e Codex per accelerare la cybersecurity aziendale

Un dettaglio non secondario: è uno dei casi più visibili in cui un modello di intelligenza artificiale viene impiegato per identificare vulnerabilità in software ampiamente diffuso. Una scoperta che apre interrogativi concreti su come evolverà la ricerca di vulnerabilità - sia dal lato difensivo che da quello offensivo.

La cronologia della divulgazione presenta qualche ambiguità. Il proof-of-concept di EQSTLab risulta pubblicato il 18 giugno 2026, ma un avviso dell'Università Keio porta la data del 5 giugno 2026 e fa già riferimento all'exploit come disponibile. È possibile che un PoC precedente - il repository mrx-arafat/CVE-2026-49975-POC, anch'esso su GitHub - sia apparso prima della pubblicazione principale. In ogni caso, le patch per Apache e nginx erano già disponibili prima della divulgazione pubblica.

Patch disponibili, ma il campo è ancora scoperto

Apache ha corretto il problema nella versione 2.4.68. nginx richiede l'aggiornamento alla versione 1.29.8 o successive. Envoy ha rilasciato la correzione il giorno successivo alla divulgazione pubblica. Microsoft ha distribuito la mitigazione per IIS nel Patch Tuesday seguente, circa una settimana dopo. Cloudflare Pingora, al momento della stesura, non dispone ancora di una patch.

Per chi non può aggiornare immediatamente, Red Hat documenta una mitigazione diretta: disabilitare HTTP/2 aggiungendo Protocols http/1.1 alla configurazione del virtual host, oppure commentare le righe di caricamento di http2_module e proxy_http2_module, oppure rimuovere h2 e h2c dalla direttiva Protocols. Il ripiego su HTTP/1.1 è trasparente per browser e client, ma comporta un degrado prestazionale reale: consegna sequenziale dei file, header di testo non compressi, più connessioni TCP, maggiore consumo di CPU e memoria. Chi non può applicare la patch può in alternativa limitare la memoria per processo a livello di sistema operativo.

L'indicatore di compromissione più immediato è una crescita anomala e sostenuta del consumo di memoria nei processi del server web.

Una vulnerabilità democratica, nel senso peggiore del termine

Imperva ha riportato che, poco dopo la divulgazione del CVE, sono stati osservati attaccanti che «utilizzavano strumenti specializzati progettati per mappare i server vulnerabili». La fase di ricognizione è in corso. Geenens di Radware, però, precisa che al momento non sono stati confermati attacchi su larga scala: la sua ipotesi è che gli attori malevoli dispongano già di molti altri metodi DoS e non abbiano ancora avuto necessità di adottare questo specifico vettore.

L'assenza di attacchi confermati non è un buon motivo per rimandare. Igal Zeifman, VP marketing di CyCognito, stima che l'80-90% dei clienti dell'azienda sia potenzialmente esposto. «Questa è una vulnerabilità che riguarda tutti», ha dichiarato Zeifman. I settori più esposti, secondo le analisi disponibili, sono telecomunicazioni e sanità, a causa delle loro ampie infrastrutture distribuite di server connessi a Internet - circa un quarto delle installazioni monitorate.

CVE-2026-49975 non punta a un settore specifico: si distribuisce ovunque Apache, nginx o gli altri server vulnerabili siano esposti su Internet con HTTP/2 abilitato. Con oltre 880.000 obiettivi potenziali già censiti, il campo d'azione per un attaccante è vasto per definizione.

Un exploit pubblico, facile da eseguire, senza autenticazione, lanciabile da un singolo computer con risorse ordinarie: chi gestisce server web esposti su Internet ha un unico compito ragionevole da completare oggi. Aggiornare ad Apache 2.4.68 o, in alternativa, disabilitare HTTP/2 finché non sarà possibile farlo. Il resto è procrastinazione.

Fonti: blog.rankiteo.com, pasqualepillitteri.it, sfc.itc.keio.ac.jp