Se Apache HTTP Server non parte più su Ubuntu 20.04 dopo gli aggiornamenti di sicurezza, il problema può essere la regressione corretta da Canonical con USN-8571-2. L’avviso, pubblicato il 10 settembre 2026, riguarda in modo specifico i sistemi con proxying HTTP/2 abilitato: il precedente aggiornamento USN-8571-1 era incompleto a causa di un simbolo di libreria mancante e poteva impedire l’avvio di Apache.
La soluzione indicata da Canonical è aggiornare i pacchetti Apache alla versione corretta. Su Ubuntu 20.04 LTS la build di riferimento è 2.4.41-4ubuntu3.23+esm7, disponibile tramite Ubuntu Pro. Prima di cambiare configurazioni o disabilitare moduli a caso, conviene quindi verificare quale versione è realmente installata.
Cosa è successo con USN-8571-1
Il 20 luglio 2026 Canonical aveva pubblicato USN-8571-1 per correggere diverse vulnerabilità di Apache HTTP Server. L’aggiornamento includeva problemi in moduli come mod_authn_socache, mod_proxy_ajp, mod_proxy_html, mod_ssl, mod_http2 e altri componenti.
Successivamente Canonical ha rilevato che la correzione era incompleta. Nel nuovo USN-8571-2 viene specificato che un simbolo di libreria mancante poteva causare una regressione e impedire l’avvio del server quando era attivo il proxying HTTP/2. L’aggiornamento del 10 settembre corregge proprio questo problema.
È importante distinguere il caso specifico: non significa che qualsiasi sito servito in HTTP/2 su Ubuntu 20.04 smetta automaticamente di funzionare. Canonical collega il difetto al proxying HTTP/2, cioè allo scenario in cui Apache agisce da proxy verso altri servizi usando HTTP/2.
Come capire se il problema è questa regressione
Se il server ha smesso di avviarsi subito dopo un aggiornamento, il primo passo è raccogliere informazioni senza modificare ancora la configurazione.
systemctl status apache2 --no-pager
journalctl -u apache2 -n 50 --no-pager
apache2ctl configtest
apt-cache policy apache2 apache2-binQuesti comandi permettono di verificare lo stato del servizio, leggere gli ultimi messaggi del journal, controllare la sintassi della configurazione e soprattutto vedere quale versione dei pacchetti Apache è installata e quale versione è disponibile nei repository configurati.
| Controllo | Cosa indica |
|---|---|
systemctl status apache2 | Se il servizio è attivo, fallito o in riavvio |
journalctl -u apache2 | Gli errori registrati durante l’avvio |
apache2ctl configtest | Eventuali errori di sintassi nella configurazione |
apt-cache policy | Versione installata e versione candidata all’aggiornamento |
Se configtest segnala un errore di sintassi reale introdotto da una modifica manuale, va risolto quello. Se invece la configurazione era funzionante e il problema è comparso insieme all’aggiornamento coinvolto da USN-8571-1, la nuova build corretta è il riferimento da controllare.
Quale versione corregge il problema
Secondo Canonical, per Ubuntu 20.04 LTS Focal i pacchetti corretti sono alla versione 2.4.41-4ubuntu3.23+esm7. L’avviso elenca, tra gli altri, apache2, apache2-bin, apache2-data, apache2-dev, apache2-utils e i pacchetti suexec e SSL collegati.
Ubuntu 20.04 ha terminato il supporto standard nel 2025, quindi questa correzione è indicata come Ubuntu Pro Fix. Se il sistema è ancora in produzione, questo dettaglio è fondamentale: un semplice apt update non può installare una versione ESM se la macchina non ha accesso ai repository previsti.
Come aggiornare Apache senza fare modifiche inutili
Su una macchina con Ubuntu Pro correttamente configurato, Canonical indica che un normale aggiornamento di sistema applica le modifiche necessarie. Prima puoi verificare lo stato del servizio Pro:
pro statusPoi aggiorna l’indice dei pacchetti e Apache:
sudo apt update
sudo apt install --only-upgrade apache2 apache2-bin apache2-data apache2-utilsDopo l’aggiornamento verifica nuovamente la versione:
apt-cache policy apache2 apache2-bin
apache2ctl -vSe la configurazione supera il test, riavvia il servizio e controlla subito lo stato:
sudo apache2ctl configtest
sudo systemctl restart apache2
systemctl status apache2 --no-pagerIl valore da confrontare resta quello indicato nell’avviso Canonical, 2.4.41-4ubuntu3.23+esm7. Se la versione candidata è più vecchia, verifica prima l’accesso a Ubuntu Pro/ESM e i repository configurati invece di forzare downgrade o installazioni manuali.
Non fare downgrade del pacchetto di sicurezza alla cieca
La tentazione, quando un servizio smette di partire dopo una patch, è tornare subito alla versione precedente. In questo caso è una scelta rischiosa perché USN-8571-1 correggeva diverse vulnerabilità di sicurezza, comprese falle in moduli proxy, SSL e HTTP/2.
La correzione raccomandata è installare l’update successivo che risolve la regressione. Un rollback dovrebbe essere valutato soltanto come misura eccezionale e controllata, comprendendo quali vulnerabilità vengono riaperte e quanto tempo il server resterà esposto.
Se non puoi ancora installare il fix
Se il server non può accedere immediatamente alla build corretta, la priorità è ridurre l’impatto senza introdurre una configurazione permanente più debole. Se la tua architettura lo consente e il proxying HTTP/2 verso il backend non è indispensabile, puoi valutare temporaneamente di usare HTTP/1.1 per il collegamento proxy fino all’installazione della patch.
Non esiste però un comando universale da copiare: ProxyPass, virtual host, mod_proxy_http2 e backend possono essere configurati in modi diversi. Salva prima la configurazione, modifica soltanto il virtual host coinvolto e verifica con apache2ctl configtest prima di riavviare.
Disabilitare HTTP/2 a livello globale senza capire la topologia non è necessario, perché l’avviso non dice che il semplice HTTP/2 lato browser sia la causa. Il problema descritto riguarda il proxying HTTP/2.
Come verificare che Apache sia tornato operativo
- controlla che
systemctl status apache2mostri il servizio attivo; - esegui
apache2ctl configteste verifica che la configurazione sia valida; - controlla il journal per nuovi errori;
- prova localmente il virtual host e poi dal percorso reale usato dagli utenti;
- se Apache lavora da reverse proxy, verifica anche il backend HTTP/2 coinvolto;
- controlla che la versione installata corrisponda a quella corretta o a una successiva fornita da Canonical.
Su server domestici o di laboratorio la stessa logica vale anche per configurazioni più semplici. Se stai costruendo l’ambiente da zero, nella nostra guida al server domestico con Ubuntu Server e Apache trovi un quadro più generale su installazione, rete e servizi da esporre.
Perché questa regressione riguarda soprattutto Ubuntu 20.04
USN-8571-2 elenca come release interessata Ubuntu 20.04 LTS. Questo non significa che Apache su 22.04, 24.04 o 26.04 sia immune da qualsiasi vulnerabilità: significa che la specifica regressione descritta nel nuovo advisory viene corretta per Focal.
Se amministri più server con versioni diverse di Ubuntu, non distribuire quindi una procedura identica a tutte le macchine. Controlla l’advisory associato alla release e i pacchetti candidati disponibili su ciascun sistema.
FAQ: Apache non parte dopo l’aggiornamento su Ubuntu 20.04
USN-8571-2 è un nuovo problema di sicurezza?
No. È un aggiornamento correttivo per una regressione introdotta dalla precedente patch USN-8571-1. Quella patch risolveva numerose vulnerabilità; la nuova revisione corregge il problema di avvio legato al proxying HTTP/2.
Quale pacchetto devo avere su Ubuntu 20.04?
Canonical indica 2.4.41-4ubuntu3.23+esm7 per apache2 e i relativi pacchetti coinvolti. Una versione successiva fornita ufficialmente può naturalmente includere la stessa correzione.
Serve Ubuntu Pro?
Per il fix indicato nell’advisory su Ubuntu 20.04, Canonical segnala la disponibilità tramite Ubuntu Pro. Verifica lo stato con pro status e la versione candidata con apt-cache policy.
Devo disattivare HTTP/2?
Non in modo generale. La regressione descritta riguarda il proxying HTTP/2. L’obiettivo è installare il pacchetto corretto; eventuali modifiche temporanee al proxy vanno limitate alla configurazione realmente coinvolta.
La sequenza più sicura è quindi: controllare i log, verificare la versione, assicurarsi che Ubuntu Pro/ESM sia disponibile, installare USN-8571-2 e testare Apache prima di intervenire sulla configurazione. In questo modo si risolve la regressione senza rinunciare alle correzioni di sicurezza introdotte dall’aggiornamento precedente.
