Impatto Sistemico

Critico (78.84)

Sintesi

Disponibili Proof of Concept (PoC) per lo sfruttamento della vulnerabilità CVE-2026-49975 – denominata “ HTTP/2 Bomb ” – che riguarda l’implementazione del protocollo HTTP/2 e che potrebbe consentire attacchi di tipo “ Denial of Service ”.

Tipologia

• Denial of Service

Descrizione

Disponibili Proof of Concept (PoC) per lo sfruttamento della vulnerabilità identificata tramite la CVE-2026-49975 – di tipo “ Resource Exhaustion ”, con score CVSS 3.1 pari a 7.5 e denominata “ HTTP/2 Bomb ” – che riguarda l’implementazione del protocollo HTTP/2 e che potrebbe consentire attacchi di tipo “ Denial of Service ”.

Tale CVE interessa le implementazioni del protocollo HTTP/2 in diversi web server (tra cui Nginx, Apache httpd, IIS, Envoy e Pingora) e deriva dalla combinazione dei seguenti fattori:

• amplificazione tramite HPACK ^[1] (compression bomb);
• assenza di limiti efficaci sulle allocazioni interne;
• abuso del meccanismo di flow control , che impedisce il rilascio della memoria.

La vulnerabilità deriva da una gestione inefficiente della memoria lato server, presente nel meccanismo di decompressione HPACK. Nel dettaglio, il protocollo consente di inserire un singolo header nella propria tabella dinamica e di referenziarlo successivamente tramite rappresentazioni compatte della stessa.

Il comportamento anomalo si verifica alla ricezione di frame contenenti il medesimo riferimento all’indice dell’header (salvato nella tabella dinamica) qualora ripetuto più volte: la ricezione di un flusso continuo di riferimenti compatti induce il server a ricostruire e allocare una copia completa di ognuno di essi, senza che tali allocazioni siano adeguatamente limitate o contabilizzate ( resource accounting ).

Di conseguenza, l’elaborazione di un payload fornito in input, per quanto di modeste dimensioni, potrebbe tradursi nella generazione di migliaia di stringhe duplicate nella RAM del server. Questo vettore di attacco può essere ulteriormente amplificato manipolando il flow control di HTTP/2: impostando, lato client, una finestra di ricezione a dimensione zero, si impedisce al server di completare l’invio delle risposte e, di conseguenza, di attivare le routine di deallocazione della memoria.

In questo scenario, un utente remoto non autenticato potrebbe sfruttare la vulnerabilità anche tramite un singolo client dotato di banda limitata (es. 100 Mbps): tale meccanismo di amplificazione consentirebbe la possibilità di saturare rapidamente decine di gigabyte di RAM in pochi secondi, provocando un DoS del server per crash o blocco operativo. L’attacco risulta particolarmente efficace in quanto aggira le tradizionali mitigazioni perimetrali e applicative basate sul controllo della dimensione massima degli header.

Prodotti e versioni affette

Web server che utilizzano HTTP/2, tra cui:

Nginx, versioni precedenti alla 1.29.8

Apache httpd, versioni con il modulo mod_http2 precedente alla v2.0.41

Envoy

• versioni precedenti alla 1.35.11
• 1.36.x, versioni precedenti alla 1.36.7
• 1.37.x, versioni precedenti alla 1.37.3
• 1.38.x, versioni precedenti alla 1.38.1

Microsoft IIS, tutte le versioni (patch non ancora disponibile)

Cloudflare Pingora, tutte le versioni (patch non ancora disponibile)

Azioni di mitigazione

Ove non provveduto, si consiglia di verificare la disponibilità di aggiornamenti di sicurezza per i prodotti in uso che utilizzano il protocollo HTTP/2.

Per i prodotti per i quali non sono ancora disponibili aggiornamenti specifici, si suggerisce, nell’attesa, di valutare le seguenti azioni di mitigazione:

• disabilitare HTTP/2, ove possibile
• in alternativa, introdurre un sistema intermedio (proxy/WAF) che imponga limiti rigidi sul numero di header per richiesta

Per ridurre la superficie d’attacco, anche in presenza di patch:

• limitare il numero massimo di header per richiesta, indipendentemente dalla dimensione totale
• configurare anche un limite sulla dimensione totale degli header decodificati (N.B. i limiti sul numero di header e sulla dimensione totale devono essere configurati in modo indipendente, poiché l’attacco sfrutta la differenza tra questi due meccanismi di controllo)
• gestire i cookie (cookie crumbs) includendoli nel conteggio degli header
• imporre timeout sugli stream bloccati, indipendentemente dall’attività dei messaggi WINDOW_UPDATE
• limitare la memoria per processo/worker (cgroups, ulimit -v, limiti dei container)
• favorire l’early OOM-kill dei worker, così che vengano riavviati rapidamente in caso di abuso
• evitare che un singolo worker consumi troppa memoria, prevenendo impatti sull’intero sistema (swap o saturazione CPU/memoria)

[1] HPACK : protocollo di compressione dei metadati (header) progettato specificamente per HTTP/2 (definito nella RFC 7541).