In breve: chi vuole far installare un aggiornamento PHP ha bisogno di più di pacchetti nuovi: contano lo stato corretto dei pacchetti, il riavvio di tutti i processi PHP e una prova che lo attesti. È esattamente ciò che fornisce il nostro servizio patch PHP. Riceve una conferma scritta per ogni server, che può esibire internamente o a terzi.
Perché un aggiornamento PHP da solo spesso non basta
Dal 21/10/2026 esistono le patch per le vulnerabilità PHP2Shell CVE-2026-109618 e CVE-2026-109619. Il BSI (l'Ufficio federale tedesco per la sicurezza informatica) raccomanda l'aggiornamento immediato. Nella pratica vediamo tre tipici ostacoli.
Primo, il numero di versione non indica sempre lo stato reale. Distribuzioni e hoster applicano in parte dei backport; in tal caso Plesk, ad esempio, continua a indicare 8.2.34 anche se lo stato dei pacchetti è aggiornato. Secondo, dopo l'installazione spesso continuano a girare vecchi processi PHP. I nuovi file sul disco non proteggono finché i vecchi worker lavorano in memoria. Terzo, su un server spesso girano in parallelo più versioni di PHP, e una di esse viene dimenticata.
Far installare l'aggiornamento PHP: le versioni corrette
| Ramo | Corretta da | Stato precedente | Nota |
|---|---|---|---|
| PHP 8.5 | 8.5.12 | 8.5.11 | verificare inoltre fatal_error_backtraces |
| PHP 8.4 | 8.4.27 | 8.4.26 | |
| PHP 8.3 | 8.3.36 | 8.3.35 | |
| PHP 8.2 | 8.2.35 | 8.2.34 | il supporto termina il 31/12/2026 |
| PHP 8.1 e precedenti | nessun aggiornamento ufficiale | – | solo backport minimi del codice sorgente per 7.4, 8.0, 8.1 |
Per i pacchetti di distribuzioni o hoster non conta il numero dopo «PHP», ma lo stato dei pacchetti che il fornitore conferma come aggiornato. Come verificarlo da soli è spiegato alla pagina Verificare correttamente versione e stato delle patch di PHP.
Come aiuta concretamente PHP SOS?
- Inventario: rileviamo tutte le installazioni PHP sul server, la modalità di esecuzione (PHP-FPM, mod_php, php-cgi, FrankenPHP, LiteSpeed) e quale sito web usa quale versione.
- Installare l'aggiornamento: installiamo le versioni corrette dalla fonte di pacchetti della Sua distribuzione, del Suo pannello o del progetto ufficiale. Per i container costruiamo insieme a Lei nuove immagini.
- Riavvio di tutti i processi: riavviamo completamente PHP-FPM, Apache, LiteSpeed o i rispettivi worker e verifichiamo che nessun processo sia più vecchio dell'aggiornamento. I retroscena sono alla pagina Riavviare PHP-FPM e tutti i worker.
- Verifica del funzionamento: richiamiamo le pagine e le funzioni più importanti, ad esempio home page, login, moduli e cassa, e controlliamo i registri degli errori.
- Conferma: riceve per ogni server un verbale con versione, stato dei pacchetti, momento del riavvio e punti aperti.
Un tipico passaggio di verifica dopo il riavvio si presenta così:
# Versione della CLI di PHP e del binario FPM (percorso a seconda del sistema)
php -v
php-fpm8.3 -v
# Ora di avvio dei processi FPM: deve essere successiva all'aggiornamento
ps -o pid,lstart,cmd -C php-fpm8.3
Casi particolari: pannelli, container e più versioni di PHP
Sui server con Plesk o cPanel le versioni di PHP provengono spesso dalle fonti di pacchetti del pannello e non dalla distribuzione. Qui verifichiamo singolarmente ogni versione installata, anche quelle che al momento non sono assegnate ad alcun sito web. Le versioni inutilizzate e obsolete le rimuoviamo previo accordo, perché non vengano riattivate per errore.
Negli ambienti Docker e Kubernetes un aggiornamento sull'host non basta. PHP si trova nell'immagine, e solo un'immagine ricostruita con una base aggiornata, distribuita su tutti i container in esecuzione, chiude la vulnerabilità. Controlliamo anche se immagini più vecchie siano ancora in uso nei registri o nei deployment. I dettagli sono alla pagina Applicare la patch a PHP nei container Docker.
Con mod_php PHP gira direttamente nel processo di Apache. Il team PHP classifica qui il rischio come il più alto. Dopo l'aggiornamento è quindi necessario riavviare completamente Apache stesso; un semplice ricaricamento della configurazione non basta in ogni caso.
Che cosa riceve da noi
- un verbale della patch per ogni server: pacchetti installati, versioni, fonte, momento
- la prova che tutti i processi PHP sono stati riavviati
- un elenco dei siti web e delle funzioni verificati
- indicazioni sui sistemi che non è stato possibile aggiornare, con motivazione
- una raccomandazione sul percorso successivo, ad esempio per PHP 8.2 a causa della prossima fine del supporto
Che cosa ci serve da Lei
- Accesso: SSH con privilegi di amministratore o accesso al pannello (Plesk, cPanel o simili)
- Finestra di manutenzione: quando è consentito un breve riavvio
- Referente: per le domande e per l'approvazione dopo la verifica del funzionamento
- Backup: conferma che esiste un salvataggio recente, oppure l'incarico di eseguirne uno prima
- Indicazioni su sviluppi propri: estensioni PHP particolari o configurazioni di cui tenere conto
Con l'hosting condiviso senza accesso diretto al server non possiamo applicare noi stessi la patch. In tal caso La aiutiamo a porre all'hoster le domande giuste e a valutarne la risposta.
Che cosa non promettiamo
Il servizio patch chiude la vulnerabilità nota. Non chiarisce se il server fosse già compromesso prima dell'aggiornamento e non rimuove il malware eventualmente introdotto. Se vuole saperlo, l'incarico adatto è l'assistenza urgente PHP2Shell con ricerca di tracce.
Per PHP 8.1 e precedenti non esistono più aggiornamenti ufficiali. In questo caso applichiamo misure provvisorie e raccomandiamo la migrazione a una versione supportata. Non diamo a memoria alcuna garanzia di compatibilità per il Suo CMS, ma la verifichiamo sulla base dei requisiti di sistema del produttore.
Domande frequenti
Perché dopo l'aggiornamento il mio server mostra ancora la vecchia versione di PHP?
Le ragioni possono essere due. O la distribuzione ha applicato un backport, e allora il numero di versione resta lo stesso anche se lo stato dei pacchetti è aggiornato. Oppure vecchi processi PHP girano ancora in memoria e vanno riavviati.
Quali versioni di PHP chiudono PHP2Shell?
La vulnerabilità è corretta in PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, pubblicate il 21/10/2026. Per i pacchetti delle distribuzioni conta lo stato dei pacchetti che il fornitore conferma come aggiornato.
L'aggiornamento può bloccare il mio sito web?
Un aggiornamento all'interno della stessa versione principale, ad esempio da 8.3.35 a 8.3.36, di norma non è critico. Un breve riavvio dei processi PHP però è necessario. Concordiamo con Lei la finestra temporale e poi controlliamo le pagine.
Con la patch è tutto risolto?
Per la vulnerabilità in sé sì, non appena tutti i processi sono stati riavviati. La patch non mostra però se qualcuno fosse già entrato prima. Per questo serve una verifica a parte.