Vulnerabilità critica in Apache permette di eseguire codice da remoto. Aggiorna subito alla 2.4.71! (aggiornato: 12 novembre 2026, ore 07:43)

Un problema di sincronizzazione fra thread, una funzione dal nome innocuo come assign_headers() e, in fondo alla catena, la possibilità di eseguire codice da remoto su un web server. Ieri, 11 novembre 2026, Apache Software Foundation ha rilasciato Apache HTTP Server 2.4.71, che corregge una vulnerabilità critica nel modulo mod_http2, identificata come CVE-2026-119618. Il modulo che gestisce HTTP/2 è attivo presso la maggior parte dei provider di hosting, e Apache, secondo i sondaggi citati dalle fonti, serve circa il 20% dei siti attivi nel mondo. Gli amministratori devono quindi aggiornare in fretta: in gioco c'è il controllo completo del processo server.

Una race condition che corrompe la heap

Apache descrive la falla come «esecuzione concorrente con una risorsa condivisa e sincronizzazione impropria». In parole povere, più flussi di esecuzione accedono alla stessa risorsa senza un meccanismo di lock adeguato. Il risultato è una corruzione della memoria heap, che può sfociare nell'esecuzione di codice da remoto. La correzione è contenuta nel commit 824beab9b9424d6cfb29595248fdbf6c3dddeab1, utile a chi compila da sorgente o mantiene patch proprie.

Sono vulnerabili le versioni dalla 2.4.55 alla 2.4.70, oltre alle release autonome di mod_h2 pubblicate su GitHub dalla 2.0.8 alla 2.0.42. C'è però una condizione: secondo Red Hat, la falla colpisce solo i server con HTTP/2 abilitato. Il protocollo è attivo esclusivamente dove la direttiva Protocols include h2 (HTTP/2 su TLS) oppure h2c (HTTP/2 in chiaro su TCP), a livello globale o di singolo virtual host.

La scoperta porta una firma inusuale. A segnalare il bug è stato per primo OSS Scanner di Anthropic, il 26 ottobre. Il 3 novembre è arrivata, in modo indipendente, anche la segnalazione di Google Cloud Vulnerability Research, a opera di Anthony Weems e Simon Scannell. Fra la prima segnalazione e la patch sono trascorse circa due settimane.

Exploit pubblico o no? Le fonti si contraddicono

Sulla gravità e sullo stato di sfruttamento il quadro non è affatto uniforme. Red Hat assegna alla vulnerabilità un punteggio CVSS di 9,8 su 10: un attaccante non autenticato, in grado di raggiungere il server, potrebbe prendere il controllo totale del processo. La valutazione di Red Hat afferma inoltre che «ricerche pubbliche hanno dimostrato un exploit affidabile» contro una configurazione predefinita con mod_http2 attivo, senza però citare né linkare tali ricerche.

Wiz, nella stessa giornata, sostiene invece che non esista alcun exploit disponibile e che non siano stati segnalati attacchi in corso. Anche l'advisory di Apache non fornisce dettagli su catene di sfruttamento o requisiti di autenticazione, e non riporta prove di attacchi attivi. Il record CVE, infine, risultava ancora "riservato" e privo di un punteggio pubblico: il 9,8 è dunque la valutazione di Red Hat, non quella ufficiale del database nazionale. Per Apache, d'altronde, l'etichetta "critica" è riservata ai bug che un attaccante remoto può usare per eseguire codice, del tipo capace di propagarsi come un worm.

Distribuzioni Linux: Red Hat ridimensiona, mod_h2 resta scoperto

Su RHEL il rischio cambia. Red Hat ha distribuito le correzioni per RHEL 9 e RHEL 10 l'11 novembre, ma su queste piattaforme classifica la falla come "importante" e non critica. I pacchetti mod_http2 di Red Hat assegnano infatti a ogni stream HTTP/2 un proprio allocatore di memoria, e questo rende l'attacco molto più difficile. RHEL 8 e le versioni precedenti non contengono il codice vulnerabile. Per RHEL 9, un esempio di pacchetto corretto è mod_http2-2.0.26-7.el9_9.1.

Debian e Amazon Linux hanno aperto le rispettive schede nei loro tracker di sicurezza; secondo The Hacker News, Ubuntu non aveva ancora una pagina dedicata. Attenzione al numero di versione: molte distribuzioni applicano le correzioni in backport senza cambiarlo. Un Apache che si dichiara 2.4.70 potrebbe quindi essere già al sicuro, e la verifica va fatta sugli advisory del distributore e sul changelog dei pacchetti.

Resta scoperto chi usa il progetto autonomo mod_h2. Su GitHub non è uscita alcuna release corretta: l'elenco si ferma alla 2.0.42, cioè l'ultima vulnerabile, e il repository è in sola lettura dal 9 giugno, quando è stato archiviato.

Gli altri due bug corretti nella 2.4.71

La nuova versione corregge altre due falle. La CVE-2026-106023, classificata "importante", è una dereferenziazione di puntatore NULL in mod_md durante l'elaborazione delle richieste. Manda in crash un processo figlio, con un impatto di tipo denial of service, e interessa le versioni dalla 2.4.30 alla 2.4.70. Quanto alla CVE-2026-109163, di gravità "bassa", è una sovrascrittura di un singolo byte nello stack in mod_vhost_alias, limitata alle versioni 2.4.69 e 2.4.70.

Il contesto non è rassicurante. A maggio la 2.4.67 aveva già corretto un double-free con possibile esecuzione di codice remoto, legato ai reset anticipati degli stream HTTP/2. A giugno la 2.4.68 ha chiuso 13 CVE e a ottobre la 2.4.69 ne ha chiuse 20. La 2.4.70 è uscita il 6 novembre, appena cinque giorni prima della 2.4.71. Sempre a giugno, l'exploit denial of service "HTTP/2 Bomb" aveva colpito le configurazioni HTTP/2 predefinite di diversi web server, Apache compreso. HTTP/2 si conferma insomma una delle parti più esposte del progetto.

Cosa fare adesso

La strada maestra è aggiornare ad Apache HTTP Server 2.4.71, partendo dai server esposti su Internet con HTTP/2 attivo. Conviene prima censire le macchine raggiungibili dall'esterno, poi validare la build corretta in un ambiente di staging e controllare il comportamento delle applicazioni dopo il rilascio. Dove mod_h2 è gestito separatamente, va verificata anche la versione del modulo.

L'advisory di Apache non propone soluzioni temporanee. Wiz suggerisce però di togliere h2 e h2c dalla direttiva Protocols, lasciando soltanto HTTP/1.1:

Protocols http/1.1

La stessa modifica protegge anche chi usa le build autonome di mod_h2, che una correzione ufficiale potrebbero non riceverla mai. Un'altra opzione è disattivare del tutto mod_http2 e mod_md, se non servono. In entrambi i casi si rinuncia a HTTP/2, con un prezzo in termini di prestazioni. È comunque un prezzo modesto rispetto a un server compromesso.

Fonti: cryptika.com, thehackernews.com, linuxcompatible.org