HTTP/2 Bomb: un byte sul filo, settanta in memoria, ripetuto finché il server cede

Due difetti vecchi, montati insieme

Nessuna delle due idee che compongono questo attacco è nuova. È il montaggio a essere efficace, ed è per questo che vale la pena guardarlo: mostra come una debolezza tollerabile presa singolarmente diventi un problema quando viene combinata con un'altra tollerabile.

HTTP/2 comprime le intestazioni con un meccanismo chiamato HPACK. L'idea è ragionevole: molte intestazioni si ripetono identiche su richieste consecutive — lo User-Agent, i cookie, l'Accept — e rispedirle ogni volta per intero è spreco. HPACK tiene quindi una tabella dinamica: la prima volta l'intestazione viaggia per esteso e viene messa in tabella; dalle volte successive basta mandare l'indice, cioè pochissimi byte, e il server ricostruisce il resto.

È compressione, ed è quindi anche un'asimmetria: quello che il client spende per mandare non è quello che il server spende per gestire. È esattamente la struttura di tutte le "bombe" di compressione, dallo ZIP bomb in poi.

La ricerca che ha portato a CVE-2026-49975 sfrutta quell'asimmetria in modo diretto. Si inserisce una volta in tabella un'intestazione quasi vuota, e poi la si referenzia migliaia di volte. Ogni riferimento costa al mittente circa un byte sul filo; al destinatario costa la contabilità interna necessaria a rappresentare quella voce — secondo la descrizione pubblica della tecnica, nell'ordine dei settanta byte per riferimento.

Il rapporto è quello che conta. Un fattore di amplificazione di quella grandezza significa che un mittente qualunque, su una connessione domestica, può far allocare al server una quantità di memoria sproporzionata rispetto a quello che gli costa produrla.

1. 01
   Passo 1

   un'intestazione quasi vuota entra una volta nella tabella dinamica HPACK
2. 02
   Passo 2

   viene referenziata migliaia di volte: ~1 byte sul filo, ~70 byte allocati
3. 03
   Passo 3

   il controllo di flusso tiene la connessione aperta, la memoria non viene liberata

Il secondo pezzo è la parte slowloris. Il controllo di flusso di HTTP/2 permette al client di regolare quanto è disposto a ricevere: se dichiara di non voler ricevere nulla, il server resta con la risposta pronta e la connessione appesa. Applicato qui, serve a impedire che la memoria venga rilasciata: le strutture allocate non vengono smontate, perché lo scambio non è finito.

Bomba di compressione più stallo: l'occupazione cresce e non scende.

Cosa dicono le fonti, e con quali numeri

Per Apache HTTP Server la posizione è netta e verificabile: il difetto sta in mod_http2, riguarda le versioni dalla 2.4.17 alla 2.4.67 e la correzione è nella 2.4.68.

I punteggi meritano un commento, perché la distanza fra i due non è un errore. CVSS v3.1 dà 7.5, che è il punteggio tipico di un denial of service raggiungibile in rete senza autenticazione: nessun impatto su riservatezza e integrità, impatto alto sulla sola disponibilità. CVSS v4.0 dà 8.7, più alto, perché la versione 4 pesa diversamente l'automatizzabilità e le condizioni di attacco. Non è che una delle due sia sbagliata: misurano cose leggermente diverse, e il numero da usare dipende da quale metrica si è adottata internamente.

Sulla portata, le fonti pubbliche descrivono l'attacco come rilevante per implementazioni HTTP/2 diffuse — sono citati nginx, Apache HTTP Server, Microsoft IIS, Envoy e Cloudflare Pingora — e circolano stime nell'ordine di centinaia di migliaia di siti potenzialmente raggiungibili in configurazione predefinita. Qui è il caso di fermarsi: quelle stime non provengono da un advisory ufficiale e la loro metodologia non è pubblica. Le riportiamo come ordine di grandezza indicato dalla ricerca, non come dato verificato.

Sul fronte prodotti, Broadcom ha pubblicato una scheda per VCF Operations e VCF Operations for Logs; 3CX e vari fornitori di protezione perimetrale hanno annunciato mitigazioni. È il segnale abituale che un difetto tocca uno strato comune a molti prodotti diversi.

Il punto che rende questa CVE poco urgente e molto interessante

Va detto chiaro, perché è la cosa che conta di più per chi deve decidere cosa patchare per primo: non risulta sfruttamento in the wild. La vulnerabilità non compare nel catalogo CISA KEV, e le fonti pubbliche di giugno 2026 riportavano esplicitamente l'assenza di attacchi osservati. Se la vostra priorità è "cosa mi sta arrivando addosso oggi", questa non è in cima alla lista.

Il che ci porta al perché ne parliamo lo stesso.

È una vulnerabilità di disponibilità pura. Nessuno entra, nessuno legge, nessuno esce con dei dati. È il vettore che le organizzazioni sistematicamente sottovalutano nella pianificazione, perché nel linguaggio interno "sicurezza" tende a voler dire "non farsi rubare le cose". Poi il servizio va giù di lunedì mattina e la conversazione cambia.

È debito tecnico di protocollo, non un errore di battitura in una riga di codice. HPACK è nato per risparmiare banda in un'epoca in cui la banda era la risorsa scarsa. Quel compromesso — spendo memoria e CPU per risparmiare rete — è stato accettato consapevolmente. Rimane sensato; ma l'asimmetria che introduce è per costruzione sfruttabile, e ogni tanto qualcuno trova il modo di misurarla per intero. Non è la prima volta che HTTP/2 produce una famiglia di DoS di questo tipo, e con ogni probabilità non sarà l'ultima.

Il costo per l'attaccante è quasi nullo. Questa è la caratteristica che rende le vulnerabilità di questo tipo appetibili anche quando il punteggio non impressiona: non serve un'infrastruttura, non serve una botnet, non serve una posizione privilegiata in rete.

Cosa fare

Aggiornare, quando il fornitore lo permette. Per Apache la strada è la 2.4.68. Per gli altri server e per gli apparati che terminano TLS e HTTP/2 per conto vostro — bilanciatori, CDN, WAF, reverse proxy — l'informazione va cercata nell'advisory del singolo fornitore, perché lo stesso identificativo si traduce in versioni diverse.

Mappare dove HTTP/2 viene effettivamente terminato. È il punto operativo più utile e quello che più spesso manca. In molte architetture il server applicativo non parla HTTP/2 con il mondo: davanti c'è un bilanciatore o una CDN. In quel caso il componente da aggiornare è quello davanti, e patchare solo il server dietro dà una falsa sensazione di lavoro fatto.

Verificare i limiti di connessione. Numero massimo di stream concorrenti, dimensione massima consentita per la tabella dinamica HPACK, timeout su connessioni che non progrediscono. Sono manopole che esistono da sempre nei server web e che in produzione restano spesso al valore predefinito. Non risolvono la vulnerabilità, ma riducono la finestra di ciò che una singola connessione può chiedere.

Sapere come si risponde a un DoS. Vale più della patch specifica, e vale anche per la prossima di questa famiglia. Chi si accorge che il servizio è giù? Quanto ci mette? Esiste un modo per mettere il servizio dietro una protezione mentre si indaga, o si va per tentativi? Sono domande a cui si risponde meglio prima.

Il punto

Non ruba niente e non lascia niente. Toglie soltanto il servizio a tutti gli altri, usando una funzione nata per essere efficiente.

L'efficienza, quando è asimmetrica, è sempre anche una leva. Il difetto non è averla scelta: è averla dimenticata.