In breve: chi gestisce ancora PHP 8.1 o precedente non riceve più dal progetto PHP aggiornamenti di sicurezza ufficiali, nemmeno per PHP2Shell. Un upgrade da PHP 8.1 a una versione supportata non è quindi un extra, ma la soluzione vera e propria. Verifichiamo le Sue applicazioni, testiamo su una copia, migriamo in modo controllato e mettiamo in sicurezza il periodo fino ad allora.
Perché PHP 8.1 e precedenti sono ora un rischio acuto
Le vulnerabilità PHP2Shell CVE-2026-109618 e CVE-2026-109619 consentono l'esecuzione di codice senza autenticazione. Sono corrette in PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Per PHP 8.1 e precedenti non esistono più aggiornamenti ufficiali, solo backport minimi del codice sorgente per 7.4, 8.0 e 8.1. Secondo la stampa specializzata sono interessate quasi tutte le versioni fino a PHP 5.4.
Alcune distribuzioni e hoster applicano backport propri. Se il Suo sistema ne faccia parte, deve confermarlo il fornitore per il Suo specifico stato dei pacchetti. Senza tale conferma dovrebbe partire dal presupposto che il server sia esposto. Che cosa significhi nel dettaglio è descritto alla pagina PHP 8.1 e precedenti: che cosa vale adesso.
Upgrade da PHP 8.1: quale versione di destinazione?
L'obiettivo dovrebbe essere una versione che il progetto PHP supporta ancora e che la Sua applicazione abilita. Lo stato aggiornato del supporto lo pubblica php.net nella pagina delle versioni supportate. PHP 8.2 termina il 31/12/2026; un passaggio a 8.2 sarebbe quindi solo una tappa intermedia con un progetto successivo ormai vicino.
Quale versione di PHP supportino il Suo CMS o sistema di shop lo verifichiamo in base ai requisiti di sistema del produttore, ad esempio su wordpress.org, shopware.com o typo3.org, e non a memoria. Spesso va prima aggiornato il CMS stesso. I vecchi shop sono un caso tipico, vedi Shopware 5: vecchi shop su una vecchia versione di PHP.
Come aiuta concretamente PHP SOS?
- Inventario e messa in sicurezza: rileviamo tutte le applicazioni, la loro versione di PHP, lo stato del CMS, le estensioni e il codice proprio. In parallelo applichiamo le misure provvisorie indicate da php.net, in modo che il rischio scenda fino alla migrazione; dettagli alla pagina WAF e virtual patching.
- Verificare la compatibilità: confrontiamo i requisiti di sistema dei produttori, verifichiamo le dipendenze con Composer e cerchiamo nel codice proprio le funzioni obsolete. Come si presenta la questione per le dipendenze è descritto alla pagina Verificare le vulnerabilità nelle dipendenze Composer.
- Test su una copia: l'applicazione gira prima in un ambiente di test con la nuova versione di PHP. Gli errori li correggiamo lì oppure li documentiamo per la Sua agenzia.
- Passaggio con via di ritorno: il passaggio in produzione avviene in una finestra di manutenzione concordata, con un backup recente e una via di ritorno definita.
- Controllo successivo: verifichiamo i registri degli errori e le funzioni centrali dopo il passaggio e rimuoviamo la vecchia versione di PHP quando non serve più.
Uno sguardo innocuo a quali siti web usino quale versione di PHP è possibile su molti sistemi tramite i pool FPM in esecuzione:
# mostrare master e pool PHP-FPM in esecuzione
ps -eo pid,cmd | grep -E "php-fpm: (master|pool)" | grep -v grep
# versioni di PHP installate (Debian/Ubuntu)
ls /etc/php/
Un upgrade a una nuova versione di PHP non rimuove il malware introdotto in precedenza. Se il server è stato esposto in rete senza protezione dal 17/10/2026, rientra nel lavoro anche una verifica delle tracce.
Ostacoli tipici nell'upgrade
La maggior parte dei problemi nel cambio di versione di PHP è prevedibile, se si sa dove cercare:
- Estensioni obsolete: plugin o moduli non più mantenuti spesso non girano sulle versioni più recenti di PHP. Per essi servono una sostituzione o un adattamento.
- Codice proprio: funzioni che PHP ha nel frattempo dichiarato obsolete o rimosso causano avvisi o interruzioni. Controlli di tipo più rigorosi portano alla luce vecchi errori di programmazione.
- Dipendenze: le librerie incluse tramite Composer richiedono talvolta a loro volta nuove versioni e trascinano con sé altre modifiche.
- Estensioni PHP sul server: non ogni estensione installata con la vecchia versione è disponibile automaticamente per la nuova.
- Cronjob e riga di comando: il sito web gira già sulla nuova versione, ma le attività pianificate richiamano ancora la vecchia versione di PHP.
Chi verifica questi punti in anticipo accorcia il passaggio ed evita sorprese in produzione.
Che cosa riceve e che cosa ci serve
Riceve una panoramica di tutte le applicazioni con versione di partenza e di destinazione, un piano di migrazione con sequenza e rischi, un verbale dei test, la documentazione del passaggio e un elenco di punti che la Sua agenzia o il Suo sviluppatore deve ancora svolgere.
Da Lei ci servono:
- accesso al server o al pannello e accesso ai backend dei CMS
- accesso al codice sorgente e al repository per gli sviluppi propri
- contatto con l'agenzia o lo sviluppatore che conoscono l'applicazione
- un ambiente di test oppure l'autorizzazione a crearne uno
- finestre di manutenzione e un referente per il collaudo
Che cosa non promettiamo
Non promettiamo che ogni vecchia applicazione giri senza modifiche su una nuova versione di PHP. Per i sistemi senza ulteriore sviluppo può essere necessaria una riprogettazione più ampia o un cambio; lo diciamo apertamente non appena si profila. Le affermazioni sulla compatibilità si basano sulle indicazioni dei produttori. E le misure provvisorie non sostituiscono la migrazione, ma coprono soltanto il tempo. I rischi a lungo termine delle versioni obsolete sono descritti alla pagina PHP end of life: rischi delle versioni obsolete.
Domande frequenti
PHP 8.1 è interessato da PHP2Shell?
Secondo la stampa specializzata sono interessate quasi tutte le versioni fino a PHP 5.4. Per PHP 8.1 e precedenti il progetto PHP non rilascia aggiornamenti ufficiali, solo backport minimi del codice sorgente per 7.4, 8.0 e 8.1. Alcune distribuzioni applicano backport propri, che il rispettivo fornitore deve confermare.
A quale versione di PHP dovrei passare?
A una versione che il progetto PHP supporta ancora attivamente e che la Sua applicazione abilita secondo i requisiti di sistema del produttore. PHP 8.2 raggiunge la fine del supporto il 31/12/2026 e quindi come obiettivo è sensato solo in parte.
Non posso semplicemente cambiare la versione di PHP nel pannello di hosting?
Tecnicamente spesso si fa con un clic. Se l'applicazione continui a funzionare dopo dipende da versione del CMS, estensioni e codice proprio. Senza un test rischia interruzioni o funzioni difettose, ad esempio nella cassa di uno shop.
E se il mio CMS non supporta la nuova versione di PHP?
In tal caso va aggiornato prima il CMS, in certi casi a una nuova versione principale. Per i sistemi senza ulteriore sviluppo può essere necessario un cambio. Fino ad allora mettiamo in sicurezza il server con misure provvisorie.