Su molti server Ubuntu il ciclo degli aggiornamenti è diventato un gesto automatico: apt update, apt upgrade, qualche pacchetto aggiornato, riavvio dei servizi. Finché la release è nella manutenzione standard, quel gesto porta anche le correzioni di sicurezza per PHP. Quando la release esce dalla manutenzione standard, il comando continua a funzionare senza errori, ma i pacchetti PHP smettono di cambiare. Nessun messaggio avverte che le nuove vulnerabilità non verranno più corrette su quel server.
In questo articolo vediamo quale versione di PHP porta ogni release LTS di Ubuntu, fino a quando arrivano le correzioni con apt, cosa cambia con Ubuntu Pro e la manutenzione estesa, come verificare in pochi minuti la situazione di un server e quali strade restano quando il PHP installato non riceve più patch.
Quale PHP c’è in ogni Ubuntu LTS
Ogni release LTS di Ubuntu include un solo ramo di PHP, scelto al momento del rilascio e mantenuto per tutta la vita della release. Il pacchetto php è un metapacchetto che punta a quel ramo, e i pacchetti veri hanno il numero nel nome: php7.4-fpm, php8.1-cli, php8.3-mysql. Tutti stanno nel repository main, quello che Canonical mantiene direttamente.
| Release | PHP incluso | Fine della manutenzione standard | Fine di ESM con Ubuntu Pro |
|---|---|---|---|
| 16.04 LTS | 7.0 | aprile 2021 | conclusa nel 2026, resta il Legacy add-on |
| 18.04 LTS | 7.2 | maggio 2023 | maggio 2028 |
| 20.04 LTS | 7.4 | maggio 2025 | maggio 2030 |
| 22.04 LTS | 8.1 | maggio 2027 | maggio 2032 |
| 24.04 LTS | 8.3 | maggio 2029 | maggio 2034 |
| 26.04 LTS | 8.5 | maggio 2031 | maggio 2036 |
La tabella mostra un punto che spesso sfugge. Il supporto di Ubuntu e quello del progetto PHP sono indipendenti. PHP 8.1 è fuori supporto ufficiale da dicembre 2025, ma su Ubuntu 22.04 il pacchetto php8.1 continua a ricevere correzioni da Canonical fino alla fine della manutenzione standard, a maggio 2027. Al contrario, un PHP installato da un repository esterno su una release ancora supportata può essere rimasto senza patch da tempo.
Cosa succede quando finisce la manutenzione standard
Ogni release LTS ha cinque anni di manutenzione standard, in cui le correzioni di sicurezza per i pacchetti di main arrivano a tutti dai repository pubblici. Dopo quella data i repository pubblici restano online ma non ricevono più correzioni di sicurezza. Quelle successive escono nei repository della manutenzione estesa, ESM, accessibili solo alle macchine collegate a un abbonamento Ubuntu Pro.
Si vede bene dalla cronologia dei pacchetti su Launchpad. L’ultimo aggiornamento pubblico di php7.4 per Ubuntu 20.04 è del 31 marzo 2025, due mesi prima della fine della manutenzione standard. Quello di php7.2 per Ubuntu 18.04 è di febbraio 2023. Su un server senza Ubuntu Pro, tutte le vulnerabilità di PHP pubblicate dopo quelle date restano aperte, anche se apt upgrade dice che il sistema è aggiornato.
Come capire se il tuo server riceve ancora patch
Bastano pochi comandi per sapere quale release stai usando, da quale repository arriva il PHP installato e se quel repository riceve ancora correzioni. Il client di Ubuntu Pro, il comando pro, è presente di default sulle release recenti e si può usare anche senza abbonamento per leggere lo stato del sistema.
# Release e stato della manutenzione
lsb_release -ds
pro status
# Quanti pacchetti installati sono coperti, e da chi (main, universe, ESM, terze parti)
pro security-status
# Da quale repository arriva il PHP-FPM installato (sostituisci 7.4 con il tuo ramo)
apt-cache policy php7.4-fpm
# Ultime correzioni di sicurezza nel changelog del pacchetto
zcat /usr/share/doc/php7.4-cli/changelog.Debian.gz | grep -m 10 -i cveNell’output di apt-cache policy guarda la riga con l’asterisco, che indica la versione installata, e le righe sotto, che indicano da dove proviene. Se compare esm.ubuntu.com il pacchetto arriva dalla manutenzione estesa. Se compare ppa.launchpadcontent.net/ondrej/php o packages.sury.org, arriva da un repository esterno e la copertura di Canonical non lo riguarda. Se compare solo /var/lib/dpkg/status, il pacchetto non è più disponibile in nessun repository configurato: è il segnale più chiaro che nessuno lo sta aggiornando.
Sullo stesso server possono convivere più rami di PHP, soprattutto quando è stato aggiunto un repository esterno. Prima di trarre conclusioni, verifica quale versione esegue davvero il sito: lo spieghiamo nell’articolo su come capire quale versione di PHP stai usando.
Ubuntu Pro e la manutenzione estesa
Ubuntu Pro è l’abbonamento di Canonical che estende la manutenzione di sicurezza di ogni release LTS a dieci anni, e fino a quindici con il componente aggiuntivo Legacy. Comprende due servizi distinti, che conviene non confondere:
- esm-infra: copre i pacchetti del repository main, quindi anche i pacchetti PHP della release, dopo la fine della manutenzione standard;
- esm-apps: estende la copertura ai pacchetti di universe, dove si trovano molte estensioni PECL e strumenti collaterali, con priorità alle vulnerabilità alte e critiche;
- uso personale: Canonical offre un abbonamento gratuito per uso personale fino a cinque macchine. Per i server aziendali serve un abbonamento a pagamento, da valutare con i termini aggiornati sul sito di Canonical.
L’attivazione è semplice e non cambia la release né il ramo di PHP. Dopo il collegamento, il normale ciclo di apt ricomincia a portare correzioni.
# Collega la macchina all’abbonamento (il token è nella dashboard di Ubuntu Pro)
sudo pro attach IL_TUO_TOKEN
# Abilita la manutenzione estesa, se non è già attiva dopo il collegamento
sudo pro enable esm-infra
sudo pro enable esm-apps
# Installa le correzioni disponibili
sudo apt update && sudo apt upgrade
# Verifica una CVE specifica senza modificare nulla, poi applica la correzione
pro fix --dry-run CVE-AAAA-NNNNN
sudo pro fix CVE-AAAA-NNNNNDue limiti vanno messi in conto. ESM corregge i pacchetti di Ubuntu, quindi non copre un PHP installato da un PPA, compilato a mano o fornito da un pannello di controllo. E non cambia la natura del ramo: PHP 7.4 su Ubuntu 20.04 con ESM riceve correzioni di sicurezza, ma resta PHP 7.4, con le stesse incompatibilità verso librerie, SDK e CMS recenti.
Il caso dei server con il PPA di Ondřej Surý
Moltissimi server Ubuntu usano il PPA ppa:ondrej/php, che permette di installare rami di PHP diversi da quello della release, più vecchi o più nuovi, anche affiancati. È una soluzione comoda e molto diffusa, ma ha una regola precisa: secondo le FAQ del progetto, sono supportate solo le release LTS in manutenzione standard. Le release che ricevono solo ESM non sono supportate, e i pacchetti delle release fuori supporto vengono rimossi poco dopo la scadenza.
In pratica, su un Ubuntu 20.04 con PHP 5.6 o 7.3 installato dal PPA, gli aggiornamenti si sono fermati con la fine della manutenzione standard della release, e Ubuntu Pro non li sostituisce perché quei pacchetti non sono di Canonical. Il server ha due problemi sovrapposti: un ramo di PHP fuori supporto e un repository che non pubblica più nulla per quella release. Se in futuro ricostruisci o reinstalli quei pacchetti, ricordati che un aggiornamento automatico può sostituirli: per evitarlo serve una regola di pinning APT.
Aggiornare la release: cosa cambia per PHP
La strada naturale per tornare nella manutenzione standard è passare alla release LTS successiva con do-release-upgrade. Per l’applicazione, però, significa cambiare ramo di PHP, perché ogni release porta il suo: da Ubuntu 20.04 a 22.04 si passa da PHP 7.4 a 8.1, e da 22.04 a 24.04 da 8.1 a 8.3. L’aggiornamento procede una release LTS alla volta, quindi da 18.04 a 24.04 i salti di PHP sono tre.
Per un sito già compatibile con il ramo successivo è un intervento di sistema come un altro, da preparare con un backup e un ambiente di prova. Per un’applicazione scritta per PHP 5.6 o 7.x, invece, l’aggiornamento della release è anche una migrazione applicativa: funzioni rimosse, avvisi diventati errori, estensioni sostituite. Farlo in produzione senza preparazione è il modo più rapido per fermare il sito.
Quando nessuna strada standard basta
Ci sono situazioni in cui né ESM né l’aggiornamento della release risolvono il problema nei tempi necessari. Le più comuni sono queste:
- il PHP in produzione arriva dal PPA o da un altro repository esterno, quindi ESM non lo copre;
- l’applicazione richiede un ramo di PHP diverso da quello della release, per esempio PHP 5.6 su Ubuntu 20.04;
- la migrazione del codice è un progetto di mesi, e nel frattempo esce una vulnerabilità grave;
- il server ospita applicazioni diverse, con requisiti di PHP diversi, e non si può aggiornare tutto insieme.
In questi casi lavoriamo con il backport delle patch di sicurezza. Partiamo dai pacchetti DEB che usi già, della distribuzione o di deb.sury.org, applichiamo le correzioni delle CVE adattate al tuo ramo e ricostruiamo i pacchetti. Li proviamo in un ambiente di prova con la tua applicazione reale e li installiamo con Ansible, con un piano di rollback. Il ramo resta lo stesso e il codice non cambia.
Il backport non rende supportata una versione fuori supporto. Chiude le vulnerabilità note e dà il tempo di pianificare la migrazione verso una release LTS attuale e un ramo di PHP supportato, senza farla sotto la pressione di un’urgenza.
Una lista di controllo per i server Ubuntu
- Elenca i server Ubuntu con la release e la data di fine della manutenzione standard.
- Per ciascuno, verifica con
apt-cache policyda quale repository arrivano i pacchetti PHP in uso. - Se arrivano da Ubuntu e la release è fuori manutenzione standard, valuta Ubuntu Pro e controlla con
pro statusche esm-infra sia attivo. - Se arrivano dal PPA o da altre fonti, controlla la data dell’ultimo aggiornamento nel changelog.
- Stima quanto lavoro serve per portare ogni applicazione al ramo di PHP della release LTS successiva.
- Decidi come proteggere la produzione fino a quel momento, e scrivilo con una data.
Se dalla verifica emerge un PHP senza patch su un server che non puoi aggiornare subito, possiamo aiutarti a valutare le opzioni: trovi i sistemi su cui interveniamo nella sezione sistemi supportati.
Conclusioni
Su Ubuntu le patch di PHP dipendono dalla release più che dal ramo: ogni LTS include un solo PHP e lo corregge per cinque anni con apt, poi solo con Ubuntu Pro e la manutenzione estesa. A ottobre 2026 PHP 7.2 su 18.04 e PHP 7.4 su 20.04 ricevono correzioni solo con ESM, mentre PHP 8.1 su 22.04 è ancora mantenuto da Canonical fino a maggio 2027. I pacchetti del PPA di Ondřej Surý seguono regole diverse e si fermano con la manutenzione standard della release. Verifica con pro status e apt-cache policy da dove arriva il tuo PHP, poi scegli tra ESM, aggiornamento della release e backport mirato, tenendo come meta un ramo di PHP supportato.
