Vulnerabilità critica in Apache HTTP Server 2.4.66: indispensabile aggiornare immediatamente

Due frame e una connessione TCP (nessuna autenticazione): è tutto quello che serve per fruttare una nuova, gravissima vulnerabilità in HTTP/2 di Apache HTTP Server. Quello descritto in CVE-2026-23918 è un bug di tipo double-free nel modulo HTTP/2 di Apache HTTP Server che, nella peggiore delle ipotesi, consente l'esecuzione di codice arbitrario da remoto. Apache Software Foundation ha rilasciato il 4 maggio la versione 2.4.67 per correggere il problema, insieme ad altre quattro vulnerabilità. Per chiunque gestisca un server web Apache - dal piccolo NAS casalingo al cluster aziendale - è il momento di aggiornare.

Il cuore del problema: un puntatore liberato due volte

La vulnerabilità risiede nel modulo mod_http2, il componente che gestisce il protocollo HTTP/2 in Apache. Il bug si annida nel percorso di pulizia degli stream all'interno del file h2_mplx.c. A scoprirlo sono stati Bartłomiej Dmitruk, co-fondatore di striga.ai, e Stanisław Strzałkowski, ricercatore di isec.pl, che hanno segnalato il problema ad Apache il 10 dicembre 2025.

Il meccanismo di innesco è quasi elegante nella sua semplicità. Un client invia un frame HTTP/2 di tipo HEADERS seguito immediatamente da un frame RST_STREAM con codice di errore diverso da zero, sullo stesso stream, prima che il multiplexer abbia avuto il tempo di registrare lo stream. Due callback della libreria nghttp2 - on_frame_recv_cb e on_stream_close_cb - scattano in sequenza rapida e invocano entrambe la funzione h2_mplx_c1_client_rst, che a sua volta chiama m_stream_cleanup. Risultato: lo stesso puntatore a una struttura h2_stream finisce due volte nell'array di pulizia.

Quando poi c1_purge_streams itera sull'array e chiama h2_stream_destroy → apr_pool_destroy per ciascun elemento, la seconda chiamata tenta di liberare memoria già liberata. Come ha spiegato Dmitruk a The Hacker News: «CVE-2026-23918 è un double-free in Apache httpd 2.4.66 mod_http2, precisamente nel percorso di pulizia degli stream di h2_mplx.c. Il bug si attiva quando un client invia un frame HEADERS HTTP/2 immediatamente seguito da RST_STREAM con un codice di errore diverso da zero sullo stesso stream, prima che il multiplexer abbia registrato lo stream».

Da crash banale a esecuzione di codice: i due scenari

Il percorso di denial of service è il più immediato e preoccupante per la sua accessibilità. Dmitruk lo ha descritto con una sintesi che non lascia spazio a equivoci: «Una connessione TCP, due frame, nessuna autenticazione, nessun header particolare, nessun URL specifico, e il worker va in crash». Apache respawna il processo, certo, ma tutte le richieste in carico al worker terminato vengono perse. L'attacco può essere sostenuto a tempo indeterminato, rendendo il servizio inutilizzabile.

Il percorso verso l'esecuzione di codice remoto (RCE) è più complesso, ma tutt'altro che teorico. I ricercatori hanno costruito un proof of concept funzionante su architettura x86_64. La catena di exploit sfrutta il riuso delle pagine di memoria tramite mmap: un attaccante piazza una struttura h2_stream contraffatta all'indirizzo virtuale appena liberato, facendo puntare la funzione di pulizia del pool ad system(). Il contenitore stabile per le strutture false e la stringa di comando è lo scoreboard di Apache, un'area di memoria che risiede a un indirizzo fisso per tutta la vita del processo server - anche con ASLR attivo.

La condizione critica è che il server utilizzi l'allocatore mmap di Apache Portable Runtime (APR). Ed è qui che molti amministratori di sistema dovrebbero drizzare le antenne: è la configurazione predefinita sui sistemi derivati da Debian - Ubuntu compreso - e sull'immagine Docker ufficiale di httpd. In laboratorio, secondo Dmitruk, «in condizioni controllate l'esecuzione arriva in pochi minuti».

Ci sono vincoli pratici: serve un information leak per ottenere gli offset di system() e dello scoreboard, e l'heap spray è probabilistico. La soglia non è altissima per un attaccante motivato. L'unica buona notizia è che il MPM prefork - la modalità di multiprocessing non basata su thread - non è vulnerabile. Peccato che la maggior parte delle configurazioni moderne usi MPM event o worker, entrambi multi-thread e quindi esposti.

» Leggi: Guida definitiva: come installare Apache su Ubuntu (server web Linux, linea di comando, VPS) (video)

La classificazione di gravità: una questione di prospettiva

Un aspetto merita chiarezza. Apache classifica internamente CVE-2026-23918 con severità «Important», secondo la propria scala. Il punteggio CVSS assegnato è invece 8.8 su 10, fascia «High». Diversi ricercatori e testate specializzate descrivono l'impatto reale come critico, considerando la superficie di attacco e la disponibilità di un exploit funzionante. La differenza riflette scale di valutazione diverse più che un disaccordo sostanziale: comunque la si classifichi, richiede attenzione immediata.

Cinque mesi tra correzione e rilascio

Un dettaglio nella cronologia salta all'occhio. La segnalazione responsabile è avvenuta il 10 dicembre 2025. La correzione è stata committata nel repository SVN di Apache il giorno successivo, con la revisione r1930444. La versione 2.4.67, quella che include la patch, è stata rilasciata pubblicamente solo il 4 maggio 2026. Quasi cinque mesi di intervallo tra la correzione privata e la disponibilità pubblica della versione aggiornata.

Non è una pratica inusuale nei progetti open source di questa portata: il coordinamento tra sviluppatori, il test delle regressioni e l'accumulo di altre correzioni nello stesso rilascio richiedono tempo. Cinque mesi restano però una finestra lunga - abbastanza perché chiunque avesse avuto accesso al commit potesse ricostruire il bug e sfruttarlo. Il rischio concreto di sfruttamento in the wild durante questo periodo è difficile da quantificare, ma non è trascurabile.

Le altre quattro vulnerabilità corrette

La versione 2.4.67 non si limita a CVE-2026-23918. Altre quattro falle sono state risolte, con gravità variabile ma comunque degne di nota per chi amministra server Apache.

• CVE-2026-24072 (moderata): un difetto in mod_rewrite legato alla valutazione di espressioni ap_expr consente agli autori di file .htaccess locali di leggere file arbitrari con i privilegi dell'utente httpd. Segnalata il 20 gennaio 2026 dal ricercatore noto come «y7syeu».
• CVE-2026-28780: un buffer overflow basato sull'heap in mod_proxy_ajp, nella funzione ajp_msg_check_header(). Un server AJP malevolo può inviare un messaggio costruito ad arte per scrivere 4 byte controllati dall'attaccante oltre il limite del buffer. Segnalata indipendentemente da quattro ricercatori tra febbraio e marzo 2026.
• CVE-2026-29168: allocazione di risorse senza limiti nel gestore di risposte OCSP di mod_md. Un attaccante può esaurire le risorse del server inviando dati OCSP sovradimensionati. Interessa le versioni dalla 2.4.30 alla 2.4.66. Segnalata il 2 marzo 2026 da Pavel Kohout di Aisle Research.
• CVE-2026-29169: dereferenziazione di puntatore NULL in mod_dav_lock. Una richiesta costruita ad hoc può mandare in crash il server. L'unico caso d'uso noto di questo modulo era con mod_dav_svn nelle versioni di Apache Subversion precedenti alla 1.2.0 - un contesto ormai quasi archeologico. Come mitigazione immediata basta rimuovere mod_dav_lock.

Chi è esposto e cosa fare adesso

Tutte le versioni di Apache HTTP Server fino alla 2.4.66 compresa sono vulnerabili. La superficie di attacco è vasta: Apache resta uno dei server web più diffusi al mondo, e la falla riguarda qualsiasi installazione con mod_http2 attivo e un MPM multi-thread - configurazione standard nella stragrande maggioranza dei casi.

Le conseguenze di uno sfruttamento riuscito vanno dalla semplice interruzione del servizio fino alla compromissione completa del sistema, con possibilità di esfiltrazione di dati o installazione di malware. Il rischio RCE è particolarmente acuto su distribuzioni derivate da Debian e su container basati sull'immagine Docker ufficiale di httpd.

La raccomandazione è scontata ma non per questo meno urgente: aggiornare alla versione 2.4.67 il prima possibile. Per chi non può farlo immediatamente, disattivare il supporto HTTP/2 elimina il vettore di attacco principale. Nel frattempo, monitorare i log alla ricerca di attività HTTP/2 anomala, reset inattesi o crash inspiegabili è una precauzione sensata. Sistemi di rilevamento intrusioni e firewall applicativi aggiungono un ulteriore livello di difesa, ma non sostituiscono la patch.

Per chi gestisce un piccolo server casalingo o un setup SOHO - Nextcloud, Gitea, un blog WordPress - il messaggio è lo stesso che per i data center, solo con meno personale a disposizione per reagire. Controllate la vostra versione di Apache, aggiornate, e se non potete farlo subito, togliete HTTP/2 dalla configurazione. Due frame bastano a rovinare il fine settimana.

Fonti: cybersecuritynews.com, cyberpress.org, sqmagazine.co.uk