Apache HTTP/2, grave falla RCE: basta una connessione TCP
CVE-2026-23918 in Apache 2.4.66: DoS con una sola connessione TCP e potenziale RCE su Debian e Docker per una double-free in mod_http2. Serve 2.4.67.
Contenuto
La Apache Software Foundation ha rilasciato il 4 maggio 2026 la versione 2.4.67 di Apache HTTP Server, correggendo CVE-2026-23918, una vulnerabilità double-free nel modulo mod_http2 che consente il crash remoto non autenticato del worker process con una sola connessione TCP. Nelle configurazioni che usano l’APR mmap allocator — il default sui sistemi Debian-derived e sull’immagine Docker ufficiale — la stessa falla apre a un percorso di esecuzione remota praticabile in laboratorio, rendendo l’aggiornamento una priorità immediata per ogni server internet-facing con HTTP/2 attivo.
- CVE-2026-23918 è una vulnerabilità double-free localizzata nel percorso di stream cleanup di
h2_mplx.cin Apache httpd 2.4.66, con punteggio CVSS di 8.8. - L’attacco di denial-of-service richiede una singola connessione TCP, due frame HTTP/2 e nessuna autenticazione per crashare il worker process.
- Il rischio di esecuzione remota si concretizza sui sistemi con APR mmap allocator, sfruttando il riutilizzo della memoria mappata e l’indirizzo fisso dello scoreboard per aggirare l’ASLR.
- MPM prefork non è affetto; per tutte le altre configurazioni con mod_http2 abilitato, il passaggio a 2.4.67 è la mitigazione definitiva.
Il meccanismo del double-free in h2_mplx.c
La vulnerabilità risiede nel modo in cui il multiplexer HTTP/2 gestisce la distruzione degli stream nel file h2_mplx.c. Quando un client invia un frame HEADERS seguito immediatamente da RST_STREAM con un codice errore diverso da zero, prima che il multiplexer registri formalmente lo stream, entrano in gioco due callback della libreria nghttp2: on_frame_recv_cb, che gestisce il reset, e on_stream_close_cb, che chiude lo stream.
Entrambi invocano la funzione h2_mplx_c1_client_rst, la quale inserisce lo stesso h2_stream pointer nell’array interno spurge. Al momento della pulizia, la prima chiamata a h2_stream_destroy libera correttamente la memoria tramite apr_pool_destroy; la seconda chiamata, tuttavia, opera su una regione già rilasciata, generando una condizione double-free. Questo errore di gestione del ciclo di vita dello stream è il cuore della falla.
DoS banale: basta una connessione TCP
La prima conseguenza è un denial-of-service remoto di estrema semplicità. L’attaccante non necessita di autenticazione, header speciali o URL specifiche: una sola connessione TCP e due frame — un HEADERS e un RST_STREAM — sono sufficienti a far terminare anomalmente il worker process di Apache.
In un ambiente con mod_http2 attivo, questo significa che un singolo endpoint esposto a internet diventa immediatamente un bersaglio ad alta efficienza per interruzioni di servizio mirate. Il crash non richiede volume di traffico né condizioni di race: basta una sequenza precisa e il processo cade. Per i servizi che fanno affidamento sulla persistenza delle connessioni HTTP/2, la stabilità complessiva del server risulta compromessa da un vettore a costo zero.
Il percorso RCE: mmap reuse e scoreboard fisso
La seconda faccia della vulnerabilità è l’esecuzione remota, condizionata all’uso di un APR con mmap allocator. Su Debian e sull’immagine Docker ufficiale di httpd, questa è la configurazione predefinita, il che allarga la superficie di attacco ben oltre i server custom. I ricercatori hanno dimostrato che, dopo il double-free, l’indirizzo virtuale liberato può essere riassegnato piazzando una fake h2_stream struct nella memoria mappata.
La funzione di cleanup della pool viene dirottata verso system(), mentre la memoria dello scoreboard — che mantiene un indirizzo fisso per tutta la vita del processo server, bypassando così l’ASLR — funge da contenitore stabile per le strutture fake e la stringa di comando. La combinazione di riutilizzo mmap e indirizzo noto trasforma una corruzione di memoria in un'esecuzione controllata, almeno nelle condizioni di laboratorio dimostrate.
"The second outcome is remote code execution, and we built a working proof of concept on x86_64. [...] The scoreboard sits at a fixed address for the lifetime of the server, even with ASLR, which is what makes the RCE path practical." — Bartlomiej Dmitruk (Striga.ai), via The Hacker News
Perché Debian e Docker amplificano il rischio
Non tutte le installazioni corrono lo stesso pericolo. MPM prefork è esplicitamente immune, poiché la sua architettura processuale non attiva il percorso vulnerabile. Tuttavia, le distribuzioni Debian-derived e il container ufficiale di Apache utilizzano by default l’APR mmap allocator, esponendo l’istanza al percorso RCE senza che l’amministratore abbia necessariamente operato scelte di configurazione esplicite.
Per altre piattaforme o configurazioni custom non è stato verificato se la stessa catena di exploitation sia altrettanto efficace: in assenza di conferme indipendenti, il rischio minimo garantito resta il crash remoto del worker. L’incognita maggiore riguarda proprio la riproducibilità pratica al di fuori del laboratorio, non essendo il proof-of-concept pubblico né testato da terze parti. Resta il fatto che, dove mmap è attivo, la teoria dell’exploit è solida.
La timeline tra segnalazione privata e rilascio pubblico
La scoperta è opera di Bartlomiej Dmitruk, ricercatore di Striga.ai, e di Stanislaw Strzalkowski di ISEC.pl. La segnalazione privata alla Apache security team è datata 10 dicembre 2025; il commit correttivo è arrivato il giorno dopo, identificato con revisione r1930444. Nonostante il fix fosse pronto in meno di ventiquattro ore dalla ricezione del report, la patch pubblica è stata inclusa soltanto nella release 2.4.67 del 4 maggio 2026.
Il ritardo ha lasciato trascorrere quasi cinque mesi tra la risoluzione interna e la disponibilità ufficiale. In questo lasso di tempo, le istanze 2.4.66 esposte a internet sono rimaste prive di mitigazione pubblica per una falla già nota al vendor. La discrepanza tra la reattività dello sviluppo interno e la tempistica del rilascio pubblico solleva interrogativi sulla gestione delle advisory coordinated di progetto open source di tale rilevanza.
Cosa fare adesso
L’aggiornamento ad Apache httpd 2.4.67 è la contromisura prioritaria e definitiva: la release corregge il double-free nel modulo mod_http2 senza richiedere interventi di configurazione aggiuntivi. Se il patching immediato non è praticabile per vincoli di manutenzione, disabilitare completamente mod_http2 interrompe il vettore di attacco senza toccare il core del server.
È opportuno verificare quale MPM è in uso: chi gira su prefork può pianificare il rollout con maggiore margine, mentre chi utilizza worker o event con APR mmap deve trattare l’intervento come critico. Come mitigazione transitoria, posizionare il server dietro un reverse proxy o una Web Application Firewall con politiche di rate limiting sui frame HTTP/2 riduce la probabilità di DoS mirato, pur non eliminando il rischio strutturale legato all’allocatore di memoria.
La gravità di CVE-2026-23918 non sta solo nella facilità del DoS, ma nella geometria dell’exploit RCE: un’allocazione di memoria riutilizzata e un indirizzo fisso dello scoreboard trasformano un’eccezione gestita in un’arma puntata contro alcune delle configurazioni più comuni del web.
Il caso solleva anche un interrogativo sulla gestione della divulgazione: un fix committato in un giorno e reso pubblico dopo quasi cinque mesi lascia un’ombra sulle finestre di esposizione che i vendor definiscono accettabili. Per le aziende, la lezione è che abilitare HTTP/2 su Apache senza aggiornare tempestivamente equivale a lasciare aperta una porta che un singolo pacchetto TCP può chiudere, o peggio.
FAQ
Quali configurazioni sono a rischio RCE e quali solo di DoS?
MPM prefork non è affetto in alcun modo. Il percorso RCE è stato dimostrato su sistemi che usano l’APR mmap allocator, configurazione predefinita su Debian e sull’immagine Docker ufficiale di httpd. Per altre piattaforme il rischio minimo accertato è il crash remoto del worker.
Perché il fix è stato committato a dicembre ma rilasciato solo a maggio?
La Apache security team ha integrato la correzione nella revisione r1930444 l’11 dicembre 2025, ma la release pubblica 2.4.67 è arrivata il 4 maggio 2026. Il motivo esatto del ritardo non è stato dettagliato dalle fonti disponibili.
L’exploit RCE è pubblico e facilmente replicabile?
No. Il proof-of-concept è stato costruito dai ricercatori in ambiente controllato su architettura x86_64, ma non è stato rilasciato pubblicamente né verificato indipendentemente. La riproducibilità pratica al di fuori delle condizioni di laboratorio resta un limite noto.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- https://thehackernews.com/2026/05/critical-apache-http2-flaw-cve-2026.html
- https://securityaffairs.com/191759/security/apache-fixes-critical-http-2-double-free-flaw-cve-2026-23918-enabling-rce.html
- https://www.vardaan-cyber.com/post/critical-apache-http-2-flaw-cve-2026-23918-enables-dos-and-potential-rce
- https://cybersecuritynews.com/apache-http-server-rce/