Un’applicazione PHP che gira da anni senza problemi dà una sensazione di solidità: le pagine si aprono, gli ordini arrivano, il gestionale fa il suo lavoro. Proprio per questo molte aziende scoprono di essere su una versione di PHP fuori supporto solo quando qualcuno lo mette per iscritto: un report di vulnerability assessment, un auditor, un fornitore che chiede di aggiornare un modulo di pagamento, oppure un avviso di sicurezza che parla di una falla grave e che, per la loro versione, non ha una correzione.
In questo articolo vediamo cosa significa davvero che una versione di PHP è in End of Life, quali rami sono già senza patch, cosa succede quando esce una nuova vulnerabilità e quali sono i rischi concreti, non solo di sicurezza, per chi decide di restare. Chiudiamo con le strade possibili e con una lista di controllo per capire da dove partire.
Cosa significa End of Life
Il progetto PHP rilascia una nuova versione principale, un nuovo ramo, ogni anno, di solito a novembre. Ogni ramo attraversa tre fasi:
- supporto attivo: il ramo riceve correzioni di bug e di sicurezza, con rilasci regolari;
- solo sicurezza: arrivano esclusivamente le correzioni per le vulnerabilità, quando necessario;
- End of Life: il ramo non riceve più alcun rilascio, nemmeno per le falle critiche sfruttabili da remoto.
Per molti anni la regola è stata di due anni di supporto attivo e uno di sola sicurezza. Nel 2024 il progetto ha approvato un aggiornamento del ciclo di rilascio: oggi ogni ramo ha due anni di supporto attivo e due di sola sicurezza, e la fine del supporto cade sempre il 31 dicembre. La modifica si è applicata anche ai rami allora supportati, per questo PHP 8.1 è rimasto in sicurezza fino alla fine del 2025.
Il punto da tenere a mente è che la fine del supporto non riguarda solo le versioni “antiche”. PHP 8.0 e 8.1 sono rami moderni, con tipizzazione, enumerazioni e prestazioni molto migliori della serie 5, eppure sono già senza patch. E PHP 8.2 esce dal supporto di sicurezza alla fine del 2026.
Quali versioni sono già senza patch
La tabella riassume la fine del supporto di sicurezza dei rami ancora diffusi in produzione. L’elenco completo, con le date esatte, è pubblicato sulla pagina dei rami non più supportati di php.net.
| Ramo | Fine del supporto di sicurezza | Stato a settembre 2026 |
|---|---|---|
| PHP 5.4 | settembre 2015 | fuori supporto da 11 anni |
| PHP 5.5 | luglio 2016 | fuori supporto da 10 anni |
| PHP 5.6 | dicembre 2018 | fuori supporto da quasi 8 anni |
| PHP 7.0 | gennaio 2019 | fuori supporto da oltre 7 anni |
| PHP 7.1 | dicembre 2019 | fuori supporto da quasi 7 anni |
| PHP 7.2 | novembre 2020 | fuori supporto da quasi 6 anni |
| PHP 7.3 | dicembre 2021 | fuori supporto da quasi 5 anni |
| PHP 7.4 | novembre 2022 | fuori supporto da quasi 4 anni |
| PHP 8.0 | novembre 2023 | fuori supporto da quasi 3 anni |
| PHP 8.1 | dicembre 2025 | fuori supporto da 9 mesi |
| PHP 8.2 | dicembre 2026 | solo sicurezza, in scadenza |
Il problema: non smette di funzionare
Il giorno dopo la fine del supporto non cambia nulla. Il server non si ferma, il sito non mostra avvisi, nessun servizio viene disattivato. È proprio questa la trappola: la fine del supporto non è un evento visibile, è l’inizio di un’esposizione che cresce nel tempo, una vulnerabilità alla volta.
Ogni anno vengono scoperte e corrette vulnerabilità nell’interprete PHP e nelle sue estensioni: nella gestione delle richieste di PHP-FPM e CGI, nel parsing di dati come XML, SOAP o immagini, nelle funzioni che leggono file e stream. Sui rami supportati la correzione arriva con un rilascio e, di lì a poco, con un aggiornamento dei pacchetti. Sui rami in End of Life la stessa falla, se presente nel codice, rimane semplicemente aperta.
Cosa succede quando esce una nuova vulnerabilità
Quando una vulnerabilità viene resa pubblica, di solito con un identificativo CVE, la descrizione del problema e spesso la correzione stessa diventano visibili a tutti. Per chi usa un ramo supportato è una buona notizia: basta aggiornare. Per chi usa un ramo fuori supporto è l’inizio di una corsa contro il tempo, perché la stessa informazione è disponibile anche a chi cerca server da attaccare.
Un esempio noto è la CVE-2019-11043, una vulnerabilità di PHP-FPM che, con alcune configurazioni diffuse di nginx, permetteva l’esecuzione di codice da remoto senza autenticazione. Le correzioni sono uscite nell’ottobre 2019 per i rami allora supportati, insieme a un exploit pubblico che ne ha reso semplice lo sfruttamento. Chi usava un ramo già fuori supporto non ha ricevuto alcun rilascio ufficiale: poteva solo cambiare la configurazione del server web, aggiornare PHP o correggere da sé il codice.
C’è però una sfumatura importante, che vedremo più avanti: non conta solo il numero di versione, ma chi mantiene il pacchetto installato. Alcune distribuzioni Linux continuano a correggere la propria versione di PHP anche dopo la fine del supporto del progetto.
I rischi, uno per uno
La sicurezza è il rischio più evidente, ma non è l’unico. Restare su un ramo abbandonato produce effetti su compatibilità, conformità e gestione operativa, e i quattro aspetti tendono a peggiorare insieme.
Sicurezza
Ogni vulnerabilità scoperta dopo la fine del supporto si aggiunge all’elenco di quelle aperte. Non tutte riguardano ogni installazione: dipende dalla SAPI usata, PHP-FPM, mod_php o CGI, dalle estensioni caricate, dalla configurazione e da quanto il server è esposto su Internet. Ma senza un’analisi puntuale non è possibile sapere quali ti riguardano, e la risposta cambia a ogni nuova CVE.
Compatibilità
L’ecosistema va avanti. Le librerie installate con Composer alzano la versione minima di PHP a ogni major: per citare due casi, Laravel 11 e Symfony 7 richiedono almeno PHP 8.2. Gli SDK dei servizi di pagamento, spedizione e fatturazione seguono la stessa strada, e i CMS alzano periodicamente la versione minima richiesta per il core, i temi e i plugin.
C’è poi il sistema operativo. Le distribuzioni recenti usano OpenSSL 3, supportato ufficialmente da PHP solo a partire dalla 8.1: compilare una versione più vecchia su un sistema moderno richiede patch dedicate. Il risultato è un blocco reciproco: non puoi aggiornare il sistema operativo perché l’applicazione richiede un PHP vecchio, e non puoi aggiornare PHP perché l’applicazione non è pronta.
Conformità
Le norme e gli standard di sicurezza non citano PHP per nome, ma chiedono tutti di gestire le vulnerabilità note del software in uso. PCI DSS, lo standard per chi tratta dati delle carte di pagamento, nella versione 4.0.1 chiede di installare entro un mese dal rilascio le patch per le vulnerabilità critiche e di gestire le altre in tempi adeguati al rischio. La direttiva NIS2, recepita in Italia con il decreto legislativo 138/2024, include la gestione delle vulnerabilità tra le misure di sicurezza obbligatorie per i soggetti coinvolti. Il GDPR chiede misure tecniche adeguate al rischio per i sistemi che trattano dati personali.
In un audit, un componente fuori supporto esposto su Internet senza un piano documentato è una non conformità difficile da giustificare. Con un piano, cioè analisi dell’esposizione, correzioni applicate e una data di migrazione, la conversazione cambia completamente.
Operatività
Chi resta a lungo su un ramo abbandonato finisce per intervenire solo in emergenza: quando esce una CVE grave, quando un fornitore smette di funzionare, quando il server va sostituito. Gli interventi fatti sotto pressione sono più rischiosi, si testano meno e costano di più. E più passa il tempo, più la distanza dalla versione supportata cresce: migrare da PHP 7.4 a 8.x è un progetto, migrare da 5.6 a 8.x è spesso un progetto molto più grande.
Il caso delle distribuzioni Linux
Sui server Linux, PHP viene quasi sempre installato con i pacchetti della distribuzione o di un repository di terze parti, e chi mantiene quei pacchetti può correggerli anche dopo la fine del supporto del progetto PHP. Per questo la stessa versione può essere protetta su un server e scoperta su un altro.
- Red Hat Enterprise Linux e derivate: le versioni di PHP distribuite con il sistema ricevono correzioni per il periodo previsto dal ciclo di vita della distribuzione o del singolo flusso applicativo, spesso più breve di quello del sistema operativo. Rocky Linux e AlmaLinux ricostruiscono gli stessi pacchetti;
- CentOS: CentOS 8 ha smesso di ricevere aggiornamenti alla fine del 2021 e CentOS 7 a giugno 2024. Su questi sistemi, senza un supporto esteso, né il sistema né PHP ricevono più patch;
- Ubuntu: nelle release LTS i pacchetti PHP della distribuzione vengono corretti durante il supporto standard, e più a lungo con l’abbonamento Ubuntu Pro;
- Debian: le correzioni arrivano dal team di sicurezza durante il supporto regolare e poi, per un periodo limitato, dal progetto Debian LTS;
- repository di terze parti, come Remi per la famiglia Red Hat o deb.sury.org per Debian e Ubuntu: sono molto diffusi perché offrono versioni diverse da quelle della distribuzione. Prima di contare sulle loro correzioni, verifica se il ramo che usi le riceve ancora.
Il modo più diretto per capire se il tuo pacchetto viene ancora corretto è leggere il suo changelog e cercare gli identificativi delle vulnerabilità:
# RHEL, CentOS, Rocky Linux, AlmaLinux, SUSE (pacchetti RPM)
rpm -q --changelog php-cli | grep -i cve | head -n 20
# Debian e Ubuntu (pacchetti DEB, il nome dipende dalla versione)
zcat /usr/share/doc/php7.4-cli/changelog.Debian.gz | grep -i cve | head -n 20Se le voci più recenti risalgono a qualche anno fa, il pacchetto non viene più mantenuto. Se invece trovi correzioni recenti, controlla comunque fino a quando sono previste: il supporto della distribuzione ha anch’esso una scadenza.
Come capire quale versione stai usando
Sullo stesso server possono convivere più versioni di PHP: una per la riga di comando, una o più per i pool di PHP-FPM, a volte un modulo di Apache. La versione che conta è quella che esegue davvero l’applicazione. Alcuni comandi utili:
# Versione della riga di comando (non sempre è quella del sito)
php -v
# Versioni di PHP-FPM installate e processi in esecuzione
ls /usr/sbin/php-fpm* /opt/remi/*/root/usr/sbin/php-fpm 2>/dev/null
ps -eo pid,args | grep -E 'php-fpm: master' | grep -v grep
# Pacchetti PHP installati
rpm -qa | grep -i php | sort # famiglia Red Hat e SUSE
dpkg -l | grep -E '^ii +php' | sort # Debian e UbuntuPer avere la certezza di cosa usa il sito, puoi creare temporaneamente un file PHP nella cartella dell’applicazione che stampi PHP_VERSION e PHP_SAPI, aprirlo nel browser e cancellarlo subito dopo: lasciarlo online espone informazioni utili a un attaccante.
Le strade possibili
Non esiste una risposta unica: dipende da quanto è grande l’applicazione, da quanto è esposta e da quanto tempo serve per renderla compatibile con un ramo supportato. Le opzioni realistiche sono quattro, e spesso si combinano.
- Migrare a un ramo supportato. È l’unica soluzione definitiva. Richiede di adeguare il codice, aggiornare librerie, temi, plugin e spesso il CMS stesso, e di testare i percorsi critici. Va pianificata, non improvvisata.
- Usare pacchetti ancora mantenuti. Se la distribuzione o un fornitore commerciale correggono ancora la tua versione, restare sui loro pacchetti, aggiornati con regolarità, ti dà tempo. Verifica la scadenza di quel supporto.
- Fare il backport delle patch. Le correzioni scritte per i rami moderni vengono adattate al codice del ramo che usi e installate al posto dei pacchetti attuali, senza toccare l’applicazione. Chiude le vulnerabilità note, ma non rende la versione supportata: ogni nuova CVE richiede una nuova valutazione.
- Mitigare. Disattivare le estensioni non usate, limitare l’accesso alle aree amministrative, filtrare le richieste con un web application firewall, isolare il server. Riduce la superficie di attacco, ma non elimina le vulnerabilità: è una misura di accompagnamento, non una soluzione.
Nella nostra esperienza, la combinazione più solida per un’applicazione importante che non può essere migrata in poche settimane è la terza insieme alla prima: backport delle patch per proteggere subito la produzione e migrazione pianificata, con test e priorità, verso un ramo supportato.
Il backport è un ponte, la migrazione è la meta.
Da dove cominciare
Se sospetti di avere server con PHP fuori supporto, queste sono le domande a cui rispondere, nell’ordine:
- quali server eseguono PHP, con quale versione e con quale SAPI;
- da dove arrivano i pacchetti installati e se ricevono ancora correzioni;
- quali applicazioni girano su ciascun server e quanto sono esposte su Internet;
- quali vulnerabilità pubblicate riguardano davvero la tua configurazione;
- quanto lavoro richiede rendere ogni applicazione compatibile con un ramo supportato;
- come proteggere la produzione nel frattempo, e fino a quando.
Le prime tre risposte si ottengono in poche ore con un inventario. Le altre richiedono un’analisi tecnica, ed è il punto da cui partiamo in ogni intervento: se vuoi, possiamo farla insieme partendo dai tuoi server. Contattaci indicando versione di PHP e sistema operativo; per un’urgenza in corso è attiva la reperibilità H24.
In conclusione
Una versione di PHP in End of Life non riceve più correzioni ufficiali, nemmeno per le vulnerabilità critiche. A settembre 2026 sono in questa situazione tutti i rami dal 5.4 all’8.1, e l’8.2 lo sarà dalla fine dell’anno. Il sito continua a funzionare, ed è per questo che il problema passa inosservato: ogni nuova CVE resta aperta, l’ecosistema di librerie e sistemi operativi si allontana, audit e norme chiedono evidenze e ogni intervento diventa un’emergenza. Prima di decidere, verifica chi mantiene i pacchetti che usi: alcune distribuzioni correggono ancora le proprie versioni. Poi scegli una strada consapevole: migrazione pianificata, pacchetti mantenuti, backport delle patch per proteggere la produzione nel frattempo, mitigazioni come misura di accompagnamento.
