Apache HTTP Server, falla in mod_http2: come verificare e aggiornare

di Irene Valli redattrice IA 12 novembre 2026, 09:34

Illustrazione 3D di due persone che controllano la sicurezza di un server rack. — Immagine generata con IA

CVE-2026-119618 colpisce mod_http2 di Apache HTTP Server dalla versione 2.4.55 alla 2.4.70. Il team di sicurezza di Apache le assegna gravità critical. L’elenco ufficiale delle vulnerabilità della 2.4 scrive che un difetto nella funzione assign_headers() «can lead to RCE», cioè può portare all’esecuzione di codice da remoto. La correzione è nella 2.4.71, rilasciata l’11 novembre 2026. Se Apache arriva dai pacchetti della distribuzione, il numero da cercare non è 2.4.71. Questa guida spiega come capire se il server è a rischio, come aggiornarlo e come disattivare HTTP/2 finché la correzione non arriva. I comandi sono quelli della documentazione ufficiale, elencata in fondo.

Cosa serve

Apache HTTP Server 2.4 su Linux, installato dai pacchetti di Debian (12 bookworm, 13 trixie) o di Ubuntu, oppure compilato dai sorgenti. Per RHEL e derivate, Windows e macOS le indicazioni sono più brevi: la documentazione consultata non scende nei dettagli.
Accesso al server da terminale, con un utente che può usare sudo.
curl con supporto HTTP/2, su qualsiasi computer, per la verifica finale.
Il nome del tuo sito, da mettere al posto di example.com negli esempi.

Dove si trova apachectl

Diversi passaggi usano apachectl, il programma che controlla il demone httpd. In un’installazione compilata dai sorgenti si trova in PREFIX/bin. PREFIX è la cartella scelta in compilazione: se non l’hai cambiata, vale /usr/local/apache2. Se il comando non viene trovato, usa il percorso completo PREFIX/bin/apachectl, come fa la pagina di installazione di Apache.

Con Apache da pacchetto, la stessa pagina avverte che percorsi e configurazione possono essere diversi e rimanda alla documentazione della distribuzione. Il controllo della configurazione e il riavvio vanno eseguiti come root.

Cosa riporta l’avviso su CVE-2026-119618

Il difetto è un errore di sincronizzazione su una risorsa condivisa durante l’esecuzione concorrente, dentro mod_http2. Il titolo dell’avviso parla di corruzione dello heap e di RCE in assign_headers. La pagina precisa che la valutazione di gravità può cambiare da una piattaforma all’altra.

Versioni colpite:

Apache HTTP Server dalla 2.4.55 alla 2.4.70, corretta nella 2.4.71;
mod_h2 distribuito su GitHub, dalla 2.0.8 alla 2.0.42.

Le fonti consultate non riportano un punteggio CVSS e non dicono se la falla sia già sfruttata. L’avviso non indica condizioni di esposizione né rimedi temporanei. Secondo la documentazione di mod_http2, le funzioni del modulo si usano solo se HTTP/2 è abilitato con la direttiva Protocols. Per questo consideriamo a rischio i server con h2 o h2c attivi e proponiamo di disattivarli come ripiego. Apache non lo indica come mitigazione ufficiale.

Debian e Ubuntu: vedere quale pacchetto apache2 è installato

Con Apache installato da apt, il numero 2.4.71 non è il riferimento. Le distribuzioni applicano la correzione alla versione che già distribuiscono (backport). Conta quindi la versione completa del pacchetto, compresa la parte dopo il trattino. Elenca i pacchetti con apache2 nel nome, come indica la guida di Ubuntu Server alla gestione dei pacchetti:

dpkg -l | grep apache2

Nella riga del pacchetto apache2 leggi la colonna della versione, per esempio 2.4.68-1~deb12u1 su Debian 12. Annotala per il confronto successivo.

Controllare se la tua distribuzione ha già la correzione

Confronta la versione installata con il security tracker della tua distribuzione. Al 12 novembre 2026 il Debian Security Tracker riporta questo stato per il pacchetto sorgente apache2:

Rilascio Debian	Versione	Stato
bookworm	2.4.68-1~deb12u1	vulnerable
bookworm (security)	2.4.67-1~deb12u3	vulnerable
trixie	2.4.68-1~deb13u1	vulnerable
trixie (security)	2.4.69-1~deb13u1	vulnerable
forky	2.4.69-1	vulnerable
sid	2.4.71-1	fixed

A quella data bookworm, trixie e forky non hanno ancora la correzione. Solo sid ce l’ha. Se usi uno di questi rilasci, applica il ripiego descritto più avanti e ricontrolla il tracker. Quando la riga del tuo rilascio passa a fixed, aggiorna.

Per Ubuntu e per RHEL, AlmaLinux e Rocky Linux parti dalla stessa pagina del tracker Debian. Nella riga «Source» ci sono i collegamenti alle pagine dello stesso CVE presso altre distribuzioni, fra cui «Ubuntu» e «Red Hat». Lì trovi lo stato del CVE e, quando è pubblicato, il pacchetto che lo corregge. Su Ubuntu Server la configurazione predefinita applica da sola gli aggiornamenti di sicurezza. Confronta comunque la versione installata con quella corretta. Chi ha Apache da pacchetto non deve compilarlo dai sorgenti.

Capire se HTTP/2 è attivo sul tuo server

L’avviso non elenca condizioni di esposizione. I tre controlli che seguono sono una nostra deduzione dalla documentazione di mod_http2, non indicazioni di Apache:

Versione. Se hai compilato Apache, lancia apachectl con l’opzione -v e leggi la versione. Con il pacchetto della distribuzione vale il controllo precedente. La pagina di apachectl spiega che le opzioni che non gestisce passano invariate a httpd, dove sono documentate.
Modulo. Lancia apachectl con l’opzione -M, che elenca i moduli caricati, e cerca http2_module: è l’identificativo di mod_http2.
Protocols. Nei file di configurazione cerca le righe Protocols che contengono h2 o h2c, nella configurazione principale e in ogni blocco <VirtualHost>. Nelle installazioni compilate il file principale è PREFIX/conf/httpd.conf. Nei pacchetti delle distribuzioni la struttura dei file è diversa: verificala nella documentazione della distribuzione.

Le due forme tipiche sono Protocols h2 http/1.1, per HTTP/2 su TLS in un VirtualHost, e Protocols h2 h2c http/1.1, che aggiunge HTTP/2 in chiaro. Se la direttiva non contiene né h2 né h2c, HTTP/2 non è attivo.

Aggiornare Apache quando arriva la correzione

Da pacchetto, su Debian e Ubuntu

Aggiorna prima l’indice dei pacchetti:

sudo apt update

Il comando aggiorna tutti i pacchetti con un aggiornamento disponibile, non solo apache2. Leggi l’elenco proposto da apt prima di confermare, soprattutto in produzione.

sudo apt upgrade

Poi assicurati che Apache sia stato riavviato per intero, con sudo systemctl restart apache2 su Debian e Ubuntu: il graceful rilegge la configurazione ma non garantisce l’avvio del nuovo eseguibile. Mettiti in conto una possibile interruzione delle connessioni. Su RHEL, AlmaLinux e Rocky Linux aggiorna con dnf i pacchetti indicati nell’avviso del fornitore, poi riavvia con sudo systemctl restart httpd.

Da sorgenti, solo se hai compilato Apache a mano

Segui la sezione «Upgrading» della pagina di installazione:

Scarica httpd-2.4.71.tar.gz dalla pagina di download e verificane l’integrità con la firma PGP (file KEYS del progetto) o con l’hash SHA256 o SHA512. Non usare un archivio che non supera la verifica.
Estrai l’archivio ed entra nella cartella httpd-2.4.71.
Copia nella nuova cartella il file config.nice della vecchia build: contiene la riga di configure usata la volta precedente.
Esegui ./config.nice, poi make, poi make install, di solito con i privilegi di root. L’installazione non sovrascrive configurazione, documenti e log.
Ferma il server con PREFIX/bin/apachectl -k graceful-stop. Prima di avviarlo con PREFIX/bin/apachectl -k start, attendi che i vecchi processi siano terminati, oppure verifica che la configurazione consenta la sovrapposizione delle istanze: Apache avverte che file di stato condivisi e programmi di rotazione dei log possono entrare in conflitto, anche distruggendo i file di log.

La stessa pagina raccomanda di provare la nuova versione prima della produzione, per esempio accanto alla vecchia con un altro --prefix e un’altra porta.

Ripiego temporaneo: togliere h2 e h2c da Protocols

Se il pacchetto corretto non è ancora disponibile, disattiva HTTP/2. Apache non la indica come mitigazione ufficiale. La proponiamo perché, secondo la documentazione di mod_http2, il modulo entra in funzione solo con h2 o h2c abilitati in Protocols. Senza h2 né h2c, Apache non controlla nemmeno se la connessione comincia con il preambolo HTTP/2.

In ogni riga Protocols, nella configurazione principale e in tutti i VirtualHost, togli h2 e h2c. Per esempio Protocols h2 http/1.1 diventa Protocols http/1.1. Non sostituisce l’aggiornamento. Dopo la modifica controlla la sintassi, come root:

apachectl -t

Se è tutto corretto, il comando risponde Syntax Ok. Altrimenti riporta l’errore: correggilo prima di andare avanti.

Riavviare Apache senza interrompere le connessioni

Il riavvio graceful serve per applicare la modifica di Protocols. Lascia completare le richieste in corso e prima controlla la sintassi della configurazione: se trova errori sintattici, non procede. Il controllo però non garantisce che il riavvio riesca. Se Apache era spento, lo avvia. Eseguilo come root e poi verifica lo stato del servizio e il registro degli errori:

apachectl -k graceful

I vecchi file di log non vengono chiusi subito. Tienine conto se usi script di rotazione dei log.

Verificare a riavvio fatto

Se hai aggiornato da pacchetto, rilancia dpkg -l | grep apache2. La versione deve coincidere con quella che la tua distribuzione indica come corretta. Il comando dice però solo quale pacchetto è installato, non quale codice è in esecuzione: conta il riavvio completo del servizio. Se hai compilato, rileggi la versione con l’opzione -v: deve essere 2.4.71.

Se hai applicato il ripiego, la prova principale è la configurazione: rileggi tutte le righe Protocols e controlla che nessuna contenga h2 o h2c. Il controllo con curl viene dopo e ha due limiti.

Secondo il manuale di curl, curl parla HTTP/2 solo se è stato compilato con quel supporto e con le opzioni giuste. Una copia senza HTTP/2 riceve HTTP/1.1 anche da un server che ha ancora h2 attivo. Prima di fidarti del risultato, lancia curl con l’opzione -V e controlla che fra le funzioni elencate compaia HTTP2.
Una richiesta a un indirizzo https:// mette alla prova solo h2. Lo stato di h2c, HTTP/2 in chiaro, si verifica soltanto sulle righe Protocols.

Interroga il sito da un’altra macchina, con il tuo dominio al posto di example.com. Il primo comando chiede solo le intestazioni della risposta:

curl -I https://example.com

Guarda la prima riga. Se compare HTTP/2, h2 è ancora attivo. Se compare HTTP/1.1, quella connessione non ha negoziato HTTP/2: il risultato da solo non dimostra che h2 sia disattivato, perché la negoziazione su HTTPS richiede anche ALPN, che dipende dalla libreria TLS di curl e può essere disabilitato. Conferma la rimozione di h2 e h2c dalla configurazione effettivamente caricata dal server.

Il secondo comando chiede esplicitamente HTTP/2 e scrive la pagina ricevuta sul terminale. Serve a controllare che il sito risponda anche quando il client propone HTTP/2: deve restituire il contenuto senza errori.

curl --http2 https://example.com

Windows e macOS

Il progetto Apache non distribuisce eseguibili per Windows: la pagina di download rimanda a distributori terzi. Su Windows installa la 2.4.71 del tuo distributore quando è disponibile. Fino ad allora applica lo stesso ripiego sulle righe Protocols di httpd.conf.

Per macOS la documentazione consultata non dà istruzioni. Aggiorna Apache dal canale da cui l’hai installato: gli aggiornamenti di Apple per la versione di sistema, Homebrew per quella di Homebrew. Poi controlla la versione e la direttiva Protocols come descritto sopra.

Rimettere HTTP/2 dopo l’aggiornamento

Con il pacchetto corretto installato, o con la 2.4.71 in funzione, riattiva HTTP/2. Rimetti h2 nelle righe Protocols dove c’era, per esempio Protocols h2 http/1.1 come nella documentazione di mod_http2. Poi rilancia come root apachectl -t e apachectl -k graceful. Infine controlla con curl -I, da una copia di curl con supporto HTTP/2, che la prima riga mostri di nuovo HTTP/2.

Documentazione di riferimento

Pagine consultate il 12 novembre 2026: