In breve: PHP end of life significa che il progetto PHP non fornisce più aggiornamenti di sicurezza per quel ramo. PHP2Shell ne mostra chiaramente le conseguenze, perché per PHP 8.1 e precedenti non esiste una correzione ufficiale e PHP 8.2 termina il 31/12/2026. Chi oggi gira su un ramo vecchio dovrebbe pianificare il passaggio adesso, non alla prossima emergenza.
Che cosa significa PHP end of life
Ogni ramo di PHP, ad esempio 8.2 o 8.3, viene mantenuto dal progetto PHP solo per un periodo limitato. Dapprima ci sono correzioni di errori e aggiornamenti di sicurezza, poi solo aggiornamenti di sicurezza. Poi il supporto termina del tutto. I periodi attuali sono pubblicati da php.net nella pagina sulle versioni supportate.
Dopo la fine del supporto il software continua a funzionare. Se però diventa nota una nuova vulnerabilità, dal progetto PHP non arriva più alcuna patch. Il server resta vulnerabile finché qualcun altro non interviene o finché Lei non passa a un ramo supportato.
Per direzione e responsabili IT è soprattutto una questione di pianificazione. Una migrazione si può preparare con calma. Sotto pressione di tempo dopo una segnalazione critica diventa costosa e rischiosa.
Che cosa mostra PHP2Shell sulle versioni obsolete
Il 21/10/2026 il progetto PHP ha pubblicato patch per due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619. Entrambe consentono l'esecuzione di codice dannoso da remoto senza autenticazione e sono valutate con CVSS v4.0 9,2. Secondo la stampa specializzata sono interessate quasi tutte le versioni fino a PHP 5.4.
| Ramo | Stato secondo il progetto PHP | Correzione PHP2Shell |
|---|---|---|
| PHP 8.5 | supportato | 8.5.12 |
| PHP 8.4 | supportato | 8.4.27 |
| PHP 8.3 | supportato | 8.3.36 |
| PHP 8.2 | supportato fino al 31/12/2026 | 8.2.35 |
| PHP 8.1, 8.0, 7.4 | nessun aggiornamento ufficiale | solo backport minimi del codice sorgente |
| PHP 7.3 e precedenti | nessun aggiornamento ufficiale | nessun backport dal progetto PHP |
Per 8.1 e precedenti resta quindi solo la via dei backport di distribuzioni o hoster. Questi mostrano spesso ancora il vecchio numero di versione anche se sono aggiornati. Se un backport sia stato applicato lo può confermare in modo vincolante solo il fornitore. I dettagli sono nella pagina PHP 8.1 e precedenti: che cosa vale ora, il quadro completo in Quali versioni di PHP sono interessate?.
PHP 8.2 ha ancora ricevuto la correzione di PHP2Shell, ma raggiunge la fine del supporto il 31/12/2026. Chi ora migra da 8.1 dovrebbe puntare direttamente a un ramo più recente.
I rischi delle versioni PHP obsolete in sintesi
Il rischio per la sicurezza è in primo piano, ma non è l'unico. Le versioni PHP obsolete si trascinano altri problemi:
- Nessuna patch per nuove vulnerabilità: ogni futura debolezza resta aperta o dipende dai backport di terzi.
- Librerie obsolete: i pacchetti attuali richiedono rami PHP più recenti. Le correzioni di sicurezza nelle librerie non si possono più applicare, come mostra la guida su composer audit.
- Dipendenza dal fornitore: gli hoster addebitano talvolta supplementi per le vecchie versioni oppure interrompono il servizio. La scadenza la decide allora il fornitore, non Lei.
- Problemi di dimostrazione: nei confronti di assicuratori, committenti o negli audit è difficile giustificare una versione non supportata. Se ne derivino conseguenze contrattuali o legali, lo chiarisca con l'assicuratore o con un avvocato.
- Sforzo di migrazione crescente: quanto maggiore è la distanza dalla versione attuale, tanto più codice va adattato.
Particolarmente interessati sono spesso i vecchi sistemi di shop e gli sviluppi personalizzati non toccati da tempo. Un esempio tipico è Shopware 5, che spesso gira ancora su rami PHP più vecchi.
Inventario: quali versioni di PHP girano da Lei?
Il primo passo è un quadro completo. Su molti server girano in parallelo più versioni di PHP, ad esempio per un vecchio sito che nessuno ha più sotto controllo. Questi comandi sono in sola lettura:
# Versione della riga di comando
php -v
# Versioni installate su Debian/Ubuntu
ls /etc/php/
# Versioni installate in Plesk
ls /opt/plesk/php/ 2>/dev/null
# Processi PHP in esecuzione con la versione nel nome
ps -eo user,cmd | grep -E "[p]hp-fpm|[p]hp[0-9.]*-cgi|[l]sphp" | sort | uniq -c
Annoti per ogni sito: dominio, versione di PHP, modalità di esecuzione, CMS con versione, persona responsabile. Questo elenco è al tempo stesso la base del Suo piano di emergenza. Nello shared hosting le versioni si trovano di solito nel menu clienti dell'hoster.
Pianificare la migrazione: come procedere
Una migrazione verso un ramo supportato segue di norma gli stessi passi, indipendentemente dal sistema:
- Definire l'obiettivo: scegliere un ramo che secondo php.net sia supportato ancora il più a lungo possibile e che, secondo i requisiti di sistema del produttore, sia adatto al Suo CMS.
- Verificare la compatibilità: CMS, estensioni, temi e codice proprio. Le indicazioni si trovano sulla pagina ufficiale del rispettivo produttore.
- Preparare lo staging: una copia del sito con la nuova versione di PHP, database incluso.
- Testare: tutti i processi importanti, dal modulo di contatto al processo d'ordine, e nel log degli errori eventuali avvisi.
- Passare e riavviare: cambiare versione, riavviare tutti i processi PHP, controllare funzionamento e log degli errori.
Pianifichi in modo realistico. Un piccolo sito con un CMS aggiornato si converte spesso rapidamente. Uno shop cresciuto negli anni con molte estensioni e codice proprio può invece richiedere un adattamento di codice ed estensioni, fino al passaggio a una nuova versione principale del sistema di shop. Chiarisca presto chi decide internamente, quale budget è disponibile e se occorra coinvolgere sviluppatori esterni.
Stabilisca inoltre come tenere d'occhio in futuro le fini del supporto. Una data fissa all'anno in cui confrontare l'elenco dei Suoi siti con le indicazioni di php.net impedisce che lo stesso collo di bottiglia si ripresenti tra due anni.
Fino al passaggio dovrebbe usare le misure provvisorie di php.net, ad esempio session.upload_progress.enabled=0 nella configurazione del server. Non sono una protezione completa, ma riducono il rischio.
Come aiuta concretamente PHP SOS?
- Rileviamo tutte le versioni di PHP, le modalità di esecuzione e le applicazioni sui Suoi server.
- Valutiamo il rischio per ogni sito e stabiliamo con Lei ordine e versione di destinazione.
- Fino alla migrazione applichiamo misure provvisorie e otteniamo dal fornitore conferme sui backport.
- Migriamo tramite un ambiente di staging e documentiamo test e passaggio.
Il procedimento è descritto nel servizio PHP 8.1 e precedenti: migrazione a una versione supportata.
Domande frequenti
Quando termina il supporto per PHP 8.2?
PHP 8.2 raggiunge la fine del supporto da parte del progetto PHP il 31/12/2026. Il ramo ha ricevuto la correzione di PHP2Shell ancora con la versione 8.2.35; per le vulnerabilità successive non è più da aspettarsi un aggiornamento ufficiale.
PHP 8.1 riceve una patch contro PHP2Shell?
Dal progetto PHP non esistono più aggiornamenti ufficiali per 8.1 e precedenti. Esistono solo backport minimi del codice sorgente per 7.4, 8.0 e 8.1. Se e come il Suo hoster o la Sua distribuzione li applichi lo deve chiedere al fornitore.
Una vecchia versione di PHP con i backport dell'hoster è sicura?
I backport possono chiudere vulnerabilità concrete, ma non sostituiscono un ramo supportato. Dipendono dal fornitore, spesso arrivano più tardi e non coprono ogni vulnerabilità. Come soluzione duratura sono quindi inadatti.
Come faccio a sapere se il mio CMS funziona con una nuova versione di PHP?
Controlli i requisiti di sistema sulla pagina ufficiale del produttore e provi in un ambiente di staging. Lo stesso vale per estensioni e temi, perché sono spesso il vero collo di bottiglia.