# Aggiornamento PHP o backport? La scelta per i sistemi legacy

> Aggiornamento PHP o backport dopo PHP2Shell? Quali tipi di backport esistono, quanto valgono e quando solo il passaggio a una versione supportata aiuta.

Fonte: https://phpsos.de/it/blog/php-upgrade-oder-backport/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**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](https://phpsos.de/it/leistungen/php-migration-legacy/). Che cosa valga senza aggiornamento ufficiale è in [PHP 8.1 e precedenti: che cosa vale ora](https://phpsos.de/it/php2shell/php-8-1-und-aelter/). 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.

1. **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.
2. **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](https://phpsos.de/it/blog/sury-repository-php/).
3. **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é.
4. **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](https://phpsos.de/it/blog/langzeitsupport-alte-php-versionen/).

## 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](https://phpsos.de/it/php/release-zyklus/).

> **Importante:**
> 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

1. **Subito:** applicare le misure provvisorie secondo php.net oppure togliere temporaneamente il sistema dalla rete, se non è disponibile una correzione documentata.
2. **Nei prossimi giorni:** installare un backport documentato, possibilmente dalla propria distribuzione o con conferma scritta del fornitore.
3. **In parallelo:** verificare la compatibilità dell'applicazione con una versione supportata e stabilire un calendario.
4. **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](https://phpsos.de/it/leistungen/php-migration-legacy/).

## 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.

## Fonti

- [PHP: versioni supportate](https://www.php.net/supported-versions.php)
- [PHP 8 ChangeLog](https://www.php.net/ChangeLog-8.php)
- [Debian Security Tracker](https://security-tracker.debian.org/)
- [Ubuntu Security Notices](https://ubuntu.com/security/notices)