In breve: se la scelta giusta sia l'aggiornamento PHP o il backport dipende da quanto a lungo deve ancora funzionare il Suo sistema e da quanto è documentato il backport. Un backport della propria distribuzione su un sistema operativo supportato è una strada a pieno titolo. Backport dai sorgenti, fonti di terzi e supporto commerciale a lungo termine per PHP 8.1 e precedenti sono ponti con scadenza. Alla lunga aiuta solo il passaggio a una versione PHP che il progetto PHP supporta ancora ufficialmente.
Perché la questione dopo PHP2Shell è urgente
Il 21/10/2026 il progetto PHP ha corretto PHP2Shell nelle versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Per PHP 8.1 e precedenti non esistono più release ufficiali, solo backport minimi dai sorgenti per 7.4, 8.0 e 8.1. Secondo la stampa specializzata sono interessate quasi tutte le versioni fino alla PHP 5.4.
Così molti gestori di sistemi legacy si trovano davanti alla stessa domanda: basta rattoppare la falla in qualche modo, o ora serve l'aggiornamento rimandato da anni? Che cosa significhi in pratica un aggiornamento lo descrive la nostra offerta di migrazione da PHP 8.1 e precedenti. Che cosa valga senza aggiornamento ufficiale è in PHP 8.1 e precedenti: che cosa vale ora. Questo articolo aiuta nella valutazione tra i due.
Quali tipi di backport esistono
«Backport» è un termine collettivo. Si intende sempre che una correzione di una versione più recente viene riportata in una più vecchia. Chi lo fa e quanto sia verificato varia però molto.
- Backport della distribuzione: Debian, Ubuntu, Red Hat e altri recepiscono le correzioni di sicurezza nei pacchetti PHP delle loro release supportate. Il numero di versione spesso resta uguale; secondo i resoconti, ad esempio Ubuntu 24.04 dopo l'aggiornamento continua a mostrare 8.3.6. La correzione si dimostra con il changelog del pacchetto e le segnalazioni di sicurezza della distribuzione.
- Fonte di terzi: il repository sury.org di Ondřej Surý ha messo a disposizione, secondo i resoconti, build per tutti i rami dalla 5.6 alla 8.5. Non è l'archivio di sicurezza di Debian. Dettagli in Il repository sury.org.
- Backport dai sorgenti del progetto PHP: per 7.4, 8.0 e 8.1 esistono patch minime nel codice sorgente, ma nessuna release pronta. Chi le usa deve compilare PHP da sé, testarlo e in futuro curarlo da sé.
- Supporto commerciale a lungo termine: fornitori come TuxCare ELS o Zend/HeroDevs offrono manutenzione per vecchie versioni. Se e quando coprano PHP2Shell va confermato per iscritto; nelle fonti note non era documentato. Di più in Supporto a lungo termine per vecchie versioni di PHP.
Aggiornamento PHP o backport: il confronto
| Criterio | Aggiornamento a versione supportata | Backport (a seconda del tipo) |
|---|---|---|
| Protezione da PHP2Shell | Sì, con 8.2.35, 8.3.36, 8.4.27 o 8.5.12 | Sì, se completo e documentato |
| Futuri aggiornamenti di sicurezza | Ufficiali fino alla fine del supporto della versione | Solo finché il rispettivo fornitore lo cura |
| Prova | Numero di versione più riavvio | Changelog del pacchetto con numeri CVE, conferma del fornitore |
| Impegno ora | Da medio ad alto, servono test di compatibilità | Basso con la distribuzione, alto con la compilazione propria |
| Impegno in seguito | Da basso fino al prossimo salto di versione | Cresce a ogni nuova falla |
| Rischio per l'applicazione | Incompatibilità con vecchio codice ed estensioni | Basso, il comportamento resta in gran parte uguale |
| Idoneità come soluzione duratura | Sì | Solo il backport della distribuzione nell'ambito di un sistema operativo supportato |
La riga «Impegno in seguito» è la più importante. PHP2Shell non sarà l'ultima falla. Ogni mese su una versione senza supporto ufficiale significa che la prossima segnalazione solleverà di nuovo la stessa domanda.
Quale versione di destinazione per l'aggiornamento?
Secondo php.net per ogni ramo PHP vale: due anni di supporto attivo, poi due anni di sole correzioni di sicurezza. Ne derivano queste date di fine del supporto di sicurezza:
| Versione | Supporto di sicurezza fino al |
|---|---|
| PHP 8.2 | 31/12/2026 |
| PHP 8.3 | 31/12/2027 |
| PHP 8.4 | 31/12/2028 |
| PHP 8.5 | 31/12/2029 |
Un aggiornamento alla 8.2 è quindi solo una breve tappa intermedia. Chi comunque migra dovrebbe puntare a una versione con un orizzonte più lungo, se CMS, shop ed estensioni la supportano. Lo verifichi nei requisiti di sistema del produttore, non a memoria. Come funziona il ciclo di release lo spiega Versioni PHP e ciclo di release.
Qualunque strada scelga: dopo l'installazione tutti i processi PHP devono essere riavviati. Un backport che si trova solo sul disco non protegge finché i vecchi worker girano in memoria.
Un ordine pragmatico per i sistemi legacy
- Subito: applicare le misure provvisorie secondo php.net oppure togliere temporaneamente il sistema dalla rete, se non è disponibile una correzione documentata.
- Nei prossimi giorni: installare un backport documentato, possibilmente dalla propria distribuzione o con conferma scritta del fornitore.
- In parallelo: verificare la compatibilità dell'applicazione con una versione supportata e stabilire un calendario.
- Nei prossimi mesi: aggiornamento alla versione di destinazione, preparato in una copia di test, con un piano di ripiego.
Vedere il backport come un ponte, non come un traguardo, è l'idea decisiva.
Quando non serve un fornitore
Se il Suo server gira su un Debian, Ubuntu o RHEL supportato e la distribuzione fornisce il backport, basta un normale aggiornamento con riavvio e uno sguardo al changelog. Lo fa da solo un admin esperto. L'aiuto conviene con compilazioni proprie, fonti di terzi, versioni molto vecchie o un'applicazione di cui nessuno ha più il quadro della compatibilità.
Come aiuta concretamente PHP SOS?
- Verifichiamo quali versioni di PHP e fonti di pacchetti girano sui Suoi server e se esiste una correzione documentata.
- Installiamo i backport, riavviamo e documentiamo la prova tramite il changelog.
- Testiamo la Sua applicazione in una copia con la versione di destinazione e indichiamo le incompatibilità.
- Pianifichiamo e accompagniamo l'aggiornamento nell'ambito della migrazione da PHP 8.1 e precedenti.
Conclusione
Il backport della distribuzione è una strada a pieno titolo, tutti gli altri backport sono ponti. Chi è bloccato su PHP 8.1 o precedente dovrebbe usare il backport per guadagnare tempo per l'aggiornamento, non per rimandarlo ancora.
Domande frequenti
Un backport è sicuro quanto un aggiornamento?
Per la falla concretamente corretta un backport può essere equivalente, se è completo e documentato. Corregge però solo ciò che è stato riportato indietro. Un aggiornamento a una versione supportata porta in più tutti i futuri aggiornamenti di sicurezza ufficiali.
Da che cosa riconosco che il mio backport copre PHP2Shell?
Dal changelog del pacchetto: lì dovrebbero essere citati i numeri CVE CVE-2026-109618 e CVE-2026-109619. Su Debian e Ubuntu lo mostra apt-get changelog, nella famiglia RHEL rpm -q --changelog. Il numero di versione da solo non è una prova.
Fino a quando PHP 8.2 riceve ancora aggiornamenti di sicurezza?
Secondo php.net il supporto di sicurezza per PHP 8.2 termina il 31/12/2026. Chi oggi aggiorna alla 8.2 dovrebbe quindi pianificare subito anche il passo successivo.
Vale la pena il supporto commerciale a lungo termine per vecchie versioni di PHP?
Può essere un ponte se un aggiornamento nel breve periodo è impossibile. Si faccia confermare per iscritto se e da quando PHP2Shell è coperta. Nelle fonti finora note non era documentato.