In breve: per PHP 8.1 e precedenti il progetto PHP non fornisce più aggiornamenti ufficiali. Il supporto a lungo termine, detto anche Extended Support, viene da distribuzioni Linux, repository di terzi o servizi commerciali come TuxCare ELS o Zend/HeroDevs. Può colmare il tempo fino all'upgrade, se il fornitore conferma per iscritto la copertura per la Sua versione. Non sostituisce però né l'upgrade né la manutenzione di CMS e codice proprio.
Perché la questione si pone proprio ora
Il 21 ottobre 2026 le correzioni di PHP2Shell sono uscite solo per i rami supportati 8.5, 8.4, 8.3 e 8.2. Per 7.4, 8.0 e 8.1 il progetto PHP ha messo a disposizione soltanto backport minimi del sorgente, cioè correzioni nel codice sorgente senza un rilascio pronto. Secondo la stampa specializzata sono interessate quasi tutte le versioni fino a PHP 5.4.
Quanto sia grande il parco installato lo mostra una valutazione di CybelAngel: circa 2,24 milioni di host PHP raggiungibili da Internet, di cui, secondo CybelAngel, il 59 per cento su versioni senza una correzione ufficiale in arrivo. Per molte aziende la questione del supporto a lungo termine non è dunque più teorica. E sta crescendo: PHP 8.2 raggiunge il 31 dicembre 2026 la fine del supporto.
Cosa serve subito a un sistema vecchio lo descrive PHP 8.1 e precedenti: cosa vale ora. Questo articolo aiuta con la domanda a medio termine: quale strada regge fino all'upgrade e cosa deve offrire?
PHP Extended Support: le strade in sintesi
| Strada | Cosa fornisce | Limiti |
|---|---|---|
| Manutenzione a lungo termine della distribuzione | Backport nei pacchetti, finché la versione della distribuzione è supportata | solo per la versione di PHP fornita da quella distribuzione |
| Repository di terzi | ad es. sury.org, secondo i rapporti con build dalla 5.6 alla 8.5 | non è l'archivio di sicurezza della distribuzione, questione di fiducia |
| Supporto commerciale a lungo termine | pacchetti aggiornati per versioni fuori supporto, ad es. TuxCare ELS, Zend/HeroDevs | far confermare la copertura per versione e CVE, costi ricorrenti |
| Compilazione in proprio da backport del sorgente | build proprie dalle correzioni del progetto PHP | oneroso, necessario di nuovo a ogni vulnerabilità |
Sulle offerte commerciali: TuxCare descrive sul proprio sito correzioni CVE per versioni fuori supporto da PHP 5.2 a 8.x, distribuite tramite la gestione dei pacchetti esistente, per Windows e le comuni distribuzioni Linux. Un avviso sulla stessa pagina segnala correzioni di PHP2Shell per versioni di PHP fuori supporto. Secondo la documentazione di cPanel, TuxCare promette per le vulnerabilità da CVSS 7 correzioni entro 14 giorni dalla pubblicazione; sui server cPanel a tale scopo i domini vengono portati da ea-php ad alt-php. Su Zend/HeroDevs non disponevamo di alcuna dichiarazione sulla copertura di PHP2Shell.
Indicazioni sulla strada dei fornitori terzi le dà l'articolo Il repository sury.org.
Cosa Le serve per iscritto dal fornitore
Il supporto a lungo termine è una prestazione di fiducia. Acquista la promessa che le future vulnerabilità vengano chiuse. Si faccia quindi rispondere per iscritto, prima della decisione:
- Quali versioni di PHP, sistemi operativi e nomi di pacchetto sono coperti esattamente?
- CVE-2026-109618 e CVE-2026-109619 sono chiuse per la Sua versione, con quale stato del pacchetto e da quando?
- Come si gestiscono CVE-2026-115560 e le future segnalazioni successive?
- Le estensioni da Lei usate sono incluse o solo il nucleo di PHP?
- Come verifica Lei stesso che una patch sia stata installata, ad esempio tramite il changelog del pacchetto?
- Per quanto tempo dura la copertura per la Sua versione e come viene annunciata una fine?
- Cosa succede ai pacchetti installati quando il contratto termina?
Risposte che rimandano solo in generale a «tutte le vulnerabilità di sicurezza» non bastano. Per revisori, assicuratori e la Sua stessa documentazione conta l'associazione concreta di versione, pacchetto e CVE.
I limiti: cosa il supporto a lungo termine non risolve
Il supporto a lungo termine mantiene aggiornato il runtime PHP. Tutto ciò che sta sopra resta compito Suo. E proprio lì, nei sistemi vecchi, di solito sta il problema maggiore.
- L'applicazione continua a invecchiare: un CMS o uno shop che richiede PHP 8.1 spesso non è esso stesso più in uso nella versione attuale.
- Librerie ed estensioni: i pacchetti Composer e i plugin spesso non ricevono più aggiornamenti per le vecchie versioni di PHP.
- Nessun sostituto di riavvio e verifica: anche i pacchetti aggiornati hanno effetto solo dopo il riavvio di tutti i processi PHP e non rimuovono il software dannoso inserito in precedenza.
- Il debito tecnico cresce: più lungo è il ponte, più grande è il salto nella migrazione successiva.
- Le prove diventano più onerose: revisori, clienti e assicuratori chiedono sempre più spesso lo stato delle patch. Una versione di PHP fuori supporto con patch di terzi si può documentare, ma richiede più spiegazioni di una versione supportata.
Quando il supporto a lungo termine è comunque la scelta giusta? Tipiche sono tre situazioni: un'applicazione specializzata il cui produttore non abilita ancora le versioni più recenti di PHP; un sistema vecchio la cui sostituzione è già decisa e che deve funzionare solo ancora per pochi mesi; oppure una grande base di codice il cui passaggio va pianificato con cura. In tutti e tre i casi il supporto a lungo termine compra tempo per una soluzione ordinata. Non è una soluzione per sistemi di cui nessuno vuole più occuparsi.
Se un sistema vecchio tra il 17 e il 21 ottobre girava non protetto su Internet, chiarisca prima se sia compromesso. Il supporto a lungo termine per un sistema già infetto non protegge nulla.
Un piano di uscita fa parte del pacchetto
Il supporto a lungo termine è una buona decisione se termina con una data. Stabilisca entro quando l'applicazione debba girare su una versione supportata, chi sia responsabile della migrazione e quali obiettivi intermedi valgano. Per quanto tempo i rami di PHP siano curati ufficialmente lo spiega Il ciclo di rilascio di PHP.
Se per il Suo sistema convenga di più un upgrade o un backport lo valuta l'articolo Upgrade di PHP o backport?.
Come aiuta concretamente PHP SOS?
- Valutare la situazione: verifichiamo versione, fonte dei pacchetti e stato delle patch dei Suoi sistemi vecchi e se mostrino tracce di un attacco.
- Verificare le offerte: confrontiamo gli impegni scritti di un fornitore di supporto a lungo termine con il Suo parco effettivo.
- Mettere in sicurezza il ponte: fino all'upgrade applichiamo le misure transitorie di php.net e limitiamo la raggiungibilità.
- Attuare l'uscita: con la migrazione da PHP 8.1 e precedenti pianifichiamo e testiamo il passaggio a una versione supportata.
Domande frequenti
Che cos'è PHP Extended Support?
Si intendono offerte che continuano a fornire correzioni di sicurezza alle versioni di PHP dopo la fine ufficiale del supporto. Possono essere distribuzioni Linux, repository di terzi o servizi commerciali come TuxCare ELS o Zend/HeroDevs.
Il supporto commerciale a lungo termine copre PHP2Shell?
TuxCare indica sul proprio sito di aver reso disponibili correzioni per PHP2Shell per versioni di PHP fuori supporto. Per la Sua versione, il Suo pacchetto e il Suo sistema operativo dovrebbe comunque farselo confermare per iscritto e ricontrollarlo nel changelog.
Il supporto a lungo termine è un'alternativa all'upgrade?
Solo per un periodo. Mantiene aggiornato il runtime PHP, ma non il CMS, le estensioni e il codice proprio, che spesso sono anch'essi obsoleti. Una data di uscita fa quindi parte di ogni decisione per il supporto a lungo termine.
Cosa succede quando il contratto di supporto a lungo termine termina?
Secondo la documentazione di cPanel su TuxCare, i pacchetti installati continuano a funzionare ma non ricevono più nuovi aggiornamenti di sicurezza. Il sistema si trova allora di nuovo nella stessa situazione di prima, solo più tardi.
L'argomento vale anche per PHP 8.2?
Sì, presto. PHP 8.2 riceve con la 8.2.35 ancora la correzione di PHP2Shell, ma il 31 dicembre 2026 raggiunge la fine del supporto. Chi usa la 8.2 dovrebbe pianificare ora il passaggio.