A volte le vulnerabilità più efficaci spuntano fuori da funzionalità che fanno esattamente quello che è previsto. È questo il caso di HTTP/2 Bomb, un attacco denial-of-service (DoS) remoto pubblicato dal gruppo di ricerca Calif che colpisce le configurazioni predefinite dei principali web server: nginx, Apache httpd, Microsoft IIS, Envoy e Cloudflare Pingora.

Partiamo subito dicendo che la scoperta ha un dettaglio che vale la pena sottolineare. A scoprire la combinazione è stato Codex, il sistema di OpenAI specializzato in lettura e sviluppo di codice. Entrambe le tecniche erano già pubbliche dal 2016, con CVE assegnate e discussioni tecniche disponibili, ma nessuno le aveva mai concatenate contro questi server. I ricercatori di Calif specificano infatti:

The other thing worth noting is how this exploit was found. Both halves have been public for a decade. What Codex did was read the codebases, recognize that the two compose, and build the combined attack. That combination is obvious once you see it, and yet as far as we can tell no human had put it together against these servers.

Un altro aspetto degno di nota è il modo in cui è stata scoperta questa vulnerabilità. Entrambe le parti erano di dominio pubblico già da un decennio. Codex ha semplicemente analizzato i codici sorgente, ha capito che i due elementi potevano combinarsi e ha messo a punto l’attacco combinato. Una volta individuata, questa combinazione appare ovvia, eppure, per quanto ne sappiamo, nessuno l’aveva mai utilizzata contro questi server.

Insomma, una catena di attacco che può ricordare quanto successo di recente con CIFSwitch.

Scendendo più nel dettaglio della vulnerabilità, HTTP/2 introduce due funzionalità pensate per migliorare le prestazioni: HPACK, lo schema di compressione degli header, e il flow control per stream. L’attacco le sfrutta entrambe e in sequenza.

Il primo attacco viene definito HPACK Indexed Reference Bomb: il client inserisce un header nella tabella dinamica di HPACK e poi invia migliaia di riferimenti indicizzati da un singolo byte ciascuno. Per ogni riferimento ricevuto il server materializza una copia completa dell’header in memoria. L’amplificazione ottenuta va da circa 70:1 su nginx fino a 5.700:1 su Envoy a causa dei meccanismi di allocazione di memoria che il server esegue per ogni campo.

La seconda si chiama Window Stall. Il client annuncia una finestra di flow control a zero byte, impedendo al server di completare l’invio della risposta e quindi di liberare la memoria appena allocata. Un frame WINDOW_UPDATE da un singolo byte arriva di tanto in tanto, quel poco che basta a resettare il timeout e tenere tutto in vita a tempo indeterminato.

Le difese già presenti nei server moderni, tipicamente un limite sulla dimensione totale degli header decodificati, non intervengono perché l’amplificazione non viene dal payload ma dalle strutture dati interne allocate per ogni campo. Per i server che invece limitano il numero di campi header, come Apache e Envoy, il bypass sfrutta una particolarità della specifica: RFC 9113 consente esplicitamente di frammentare l’header Cookie in un campo separato per ogni valore, e in entrambi i casi questi frammenti non venivano conteggiati contro i limiti configurati.

Come mostrato dai ricercatori di Calif, il risultato pratico è che un computer domestico su una connessione da 100 Mbps riesce a portare un server vulnerabile a esaurimento di RAM in pochi secondi. Nei test, Envoy 1.37.2 ha raggiunto 32 GB in circa 10 secondi, Apache httpd 2.4.67 in 18, nginx 1.29.7 in 45, Microsoft IIS su Windows Server 2025 ha toccato 64 GB in 45 secondi.

Una PoC dell’attacco HTTP/2 Bomb è presente su GitHub, ma fortunatamente è possibile già mettere in atto dei meccanismi di difesa:

nginx ha risolto nella versione 1.29.8 con la nuova direttiva max_headers, il cui default è 1000. Chi non può aggiornare subito può disabilitare HTTP/2 aggiungendo http2 off; nella configurazione.

Apache httpd ha la patch in mod_http2 v2.0.41, disponibile come release standalone e nel trunk, ma non ancora inclusa in un rilascio 2.4.x stabile al momento della divulgazione. La CVE assegnata è CVE-2026-49975. La mitigazione temporanea è disabilitare HTTP/2 con Protocols http/1.1. Abbassare LimitRequestFieldSize riduce il raggio d’impatto per singolo stream, ma non risolve il problema perché l’attacco scala facilmente su stream e connessioni multiple.

Per IIS, Envoy e Pingora non era disponibile una patch al momento della divulgazione. Envoy ne ha rilasciata una il 3 giugno, ancora in fase di validazione da parte dei ricercatori. Cloudflare ha però dichiarato che le proprie infrastrutture di mitigazione DDoS rilevano e bloccano l’attacco automaticamente, senza necessità di intervento per i clienti.

Una misura difensiva valida per tutti, indipendentemente dallo stato delle patch, è limitare la memoria per processo tramite cgroup, ulimit o container limits. Insomma, preferiamo un worker che va in OOM e si riavvia piuttosto che la memoria di un server intero saturata dall’attaccante.