PHP2Shell, i dubbi più comuni: a che versione aggiornare PHP, come controllare se sei a rischio e quanto è grave

Se il tuo sito sta su un hosting condiviso, la correzione per PHP2Shell la applica l’hosting: tu controlla di essere almeno su PHP 8.2 e scrivigli per avere conferma. Se hai un server tuo, devi aggiornare PHP tu, oggi. Le versioni corrette ufficiali sono 8.2.35, 8.3.36, 8.4.27 e 8.5.12, ma su Ubuntu il numero di versione non cambia mai, anche dopo la correzione. Per questo molti stanno controllando il numero sbagliato.

PHP2Shell è la falla di PHP trovata con l’aiuto di GPT-5.6 Sol, e PHP gira sul 70% dei siti web. Dopo il mio primo Short sulla falla mi avete scritto tantissimi dubbi. Qui rispondo a tutti, nell’ordine del video:

1. A che versione aggiornare PHP, e chi deve farlo.
2. Come controllare se sei a rischio, anche quando il numero di versione sembra dire il contrario.
3. Quanto è grave davvero: le tre obiezioni più comuni.
4. Perché PHP ha annunciato la falla prima della correzione.
5. Perché falle come questa, trovate con l’AI, ne vedremo sempre di più.

Se vuoi prima capire cos’è PHP2Shell e cosa può fare un attaccante, ho spiegato la falla e i primi passi per proteggere il sito qui.

A che versione devo aggiornare PHP per PHP2Shell?

Nel primo Short ho detto di aggiornare almeno alla 8.2. È un buon punto di partenza, ma non basta: il numero giusto dipende da chi ti ha dato PHP. Ci sono tre casi.

Caso 1: il sito sta su un hosting condiviso

Su un hosting condiviso, come Aruba, Hostinger o SiteGround, PHP non lo installi tu: lo gestisce l’hosting, e la correzione per PHP2Shell la deve applicare lui. Tu puoi fare due cose:

• nel pannello dell’hosting, controlla di usare PHP 8.2 o una versione più recente;
• scrivi all’hosting e chiedi se ha già applicato la correzione.

Molti di voi mi hanno scritto che il loro hosting ha aggiornato tutto in poche ore, ed è molto probabile. Chiedere però non costa nulla e una risposta scritta ti toglie ogni dubbio. Questa è la mail che ho preparato, da copiare:

Oggetto: Correzione PHP2Shell

Buongiorno,
il mio sito è ospitato sul vostro servizio.
Potete confermarmi che la versione di PHP che usa ha già la correzione
per PHP2Shell (CVE-2026-109618 e CVE-2026-109619)?
Se non ce l'ha, quando la applicherete?

Caso 2: server tuo, PHP preso da php.net o da Docker

Se hai un server tuo, per esempio una VPS (Virtual Private Server), e PHP l’hai installato dal sito ufficiale di PHP oppure gira in un container Docker ufficiale, il numero di versione conta. Le versioni corrette pubblicate da PHP il 21 ottobre 2026 sono:

• 8.2.35
• 8.3.36
• 8.4.27
• 8.5.12

o successive. Se sei su una versione più vecchia della 8.2, non esiste una versione corretta pronta da installare: devi passare alla 8.2 o a una più recente. Per 7.4, 8.0 e 8.1 il team di PHP ha pubblicato solo correzioni minime da compilare a mano, pensate per chi compila PHP da sé.

Aggiornare PHP rompe il sito?

Aggiornare PHP rompe il sito solo se cambi versione principale. Passare dalla 8.2.20 alla 8.2.35 è come installare un aggiornamento di sicurezza sul telefono: contiene solo correzioni e non si rompe nulla. Passare da PHP 7 a PHP 8 è come passare da Windows 10 a Windows 11: alcune parti del sito possono smettere di funzionare.

In quel caso il consiglio è fare l’aggiornamento prima su una copia del sito, controllare che tutto funzioni e solo dopo applicarlo al sito vero. In alternativa, chiedi a chi ti ha fatto il sito.

L’eccezione di CloudPanel

Io ho una VPS su Hostinger, e la notte del 21 ottobre Hostinger mi ha mandato una mail sulla falla. Dice che, se sulla VPS hai installato CloudPanel, il pannello che molti usano per gestire una VPS, gli aggiornamenti automatici non includono la correzione per PHP2Shell. Con CloudPanel la patch va installata a mano.

Caso 3: server tuo, PHP installato con i pacchetti di Ubuntu

Se il server usa Ubuntu e PHP l’hai installato con i pacchetti di Ubuntu (sudo apt-get install php), il numero di versione non cambia mai. Ubuntu prende la correzione e la inserisce nel pacchetto che hai già. Sulla mia VPS, prima e dopo l’aggiornamento, PHP diceva sempre 8.3.6. Cambia solo la parte finale del nome del pacchetto.

Quindi su Ubuntu, se cerchi il numero 8.3.36, non lo troverai mai, anche se sei già protetto. Le versioni corrette dei pacchetti, secondo la pagina di sicurezza di Ubuntu, sono:

• Ubuntu 24.04: 8.3.6-0ubuntu0.24.04.13
• Ubuntu 22.04: 8.1.2-1ubuntu2.28
• Ubuntu 20.04, solo con Ubuntu Pro: 7.4.3-4ubuntu2.29+esm5

Debian si comporta in modo diverso e passa al numero nuovo: secondo il tracker di sicurezza di Debian, su Debian 12 il pacchetto corretto è 8.2.35-1~deb12u1, su Debian 13 è 8.4.27-1~deb13u1.

Come controllo se il mio PHP è vulnerabile a PHP2Shell?

Il modo più semplice su un server tuo è chiedere a Claude Code di controllare il pacchetto installato. Lo strumento gratuito di OpenAI su GitHub è utile, ma guarda solo il numero di versione, e su Ubuntu il numero non cambia. L’ho verificato sulla mia VPS.

Il test sulla mia VPS

Sulla mia VPS con Ubuntu 24.04 ho installato apposta la versione di PHP che Ubuntu distribuiva prima della correzione. Poi ho lanciato questi comandi, nell’ordine:

php -v
node phpcheck.js --local
sudo apt-get install --only-upgrade php8.3-cli php8.3-common php8.3-opcache php8.3-readline
php -v
node phpcheck.js --local

Ecco cosa è successo:

1. php -v risponde PHP 8.3.6, compilato il 15 aprile 2024.
2. Lo strumento di OpenAI risponde VULNERABLE: PHP 8.3.6. Corretto.
3. Aggiorno i pacchetti PHP: su Ubuntu basta un comando, e arriva il pacchetto 8.3.6-0ubuntu0.24.04.13.
4. php -v risponde di nuovo PHP 8.3.6, ma la data di compilazione è diventata 19 ottobre 2026.
5. Lo strumento di OpenAI risponde ancora VULNERABLE: PHP 8.3.6.

Numero di versione uguale, data diversa. Il PHP è stato ricompilato con la correzione, ma lo strumento di OpenAI guarda solo il numero, quindi non se ne accorge. Il limite è scritto anche nel README dello strumento: gli header HTTP non possono dire se una versione contiene una correzione portata indietro dalla distribuzione. E se lo strumento risponde UNKNOWN, non vuol dire che sei al sicuro: vuol dire che non è riuscito a capirlo.

Il prompt che ho dato a Claude Code

Tutti questi controlli li ho fatti fare anche a Claude Code, con Opus 5.5 ed effort medio, con una sola frase:

Controlla se il PHP installato su questo server è vulnerabile a PHP2Shell e, se lo è, sistemalo.

Claude Code ha cercato da solo cos’è PHP2Shell e qual è la correzione per Ubuntu 24.04. Poi ha analizzato il sistema, ha visto che il pacchetto installato non era quello corretto e ha aggiornato solo i quattro pacchetti php8.3, senza toccare il resto del server. Alla fine mi ha spiegato da solo: “php -v mostra ancora 8.3.6, ed è normale: Ubuntu applica la correzione senza cambiare il numero di versione.”

Su un server tuo è il modo più semplice per risolvere, ed è quello che ti consiglio. Se i comandi non vuoi scriverli tu, chiedili a Claude Code. Su un server con un sito vero, dopo l’aggiornamento va riavviato anche il processo che esegue PHP, per esempio PHP-FPM o Apache.

Su hosting condiviso con WordPress

Su WordPress la versione di PHP si trova in Strumenti › Salute del sito › Info › Server. Anche lì vale lo stesso discorso di Ubuntu: alcuni hosting correggono la falla senza cambiare il numero di versione. Per questo la mail all’hosting resta il modo più sicuro per sapere se il tuo sito è protetto.

Quanto è grave davvero PHP2Shell?

PHP2Shell è grave abbastanza da aggiornare oggi. Sotto i miei video qualcuno mi ha accusato di fare terrorismo, e alcune obiezioni erano serie. Le prendo una per una.

“Le password sono criptate”

Le password degli utenti del sito, di solito, sono salvate in un modo che non si può leggere, anche se qualcuno accede al database. Il sito però ha bisogno di altre password per funzionare: quella del database, le chiavi API dei pagamenti, le chiavi API delle email. Queste sono scritte in chiaro nei file del sito, perché il sito stesso deve leggerle.

L’avviso ufficiale di PHP descrive l’impatto come esecuzione di codice da remoto, senza autenticazione, con l’account che esegue il sito. Chi sfrutta PHP2Shell ha quindi gli stessi permessi del sito, e quelle chiavi le legge.

“Se il sito gira in un container o con permessi limitati, siamo tranquilli”

Un container Docker o un utente con permessi limitati impediscono all’attaccante di prendere il controllo del resto del server. Sono ottime pratiche. Dentro quel container, però, c’è proprio il tuo sito, con i suoi file e le sue chiavi. Il container protegge gli altri siti sullo stesso server, il sito attaccato no.

“È sfruttabile solo in laboratorio”

La risposta è nell’avviso ufficiale di PHP. Su Apache con mod_php, nella configurazione di default, l’attacco completo è stato dimostrato via internet, senza password. Su PHP-FPM, la configurazione di molti server con Nginx, l’analisi del codice dice che la falla c’è, ma nessuno ha ancora dimostrato un attacco completo. E Cloudflare ha detto di aver già visto i primi tentativi di attacco contro i siti che protegge.

Il verdetto

Lo dice PHP stesso nell’avviso ufficiale: aggiornare a una versione con la correzione è l’unica protezione completa. Tutto il resto riduce il rischio, ma non lo toglie.

Perché PHP ha annunciato la falla prima della correzione?

PHP ha annunciato la falla un giorno prima della correzione perché segue la divulgazione coordinata: un preavviso pubblico, senza dettagli, serve a chi gestisce i server per prepararsi e installare la correzione appena esce. Funziona così:

1. chi trova la falla la segnala in privato a chi mantiene il software;
2. insieme preparano la correzione in segreto;
3. nel frattempo vengono avvisate in privato le distribuzioni Linux, come Ubuntu e Debian, che preparano i loro pacchetti;
4. qualche giorno o un giorno prima del rilascio arriva un preavviso pubblico: “sta arrivando una correzione critica, preparatevi”, senza dire dove sta la falla;
5. esce la correzione, insieme ai dettagli.

Per PHP2Shell la linea del tempo, secondo Wiz e php.net, è questa:

• 19 agosto 2026: Wiz trova la prima falla;
• 24 agosto: la segnala al team di sicurezza di PHP;
• 21 settembre: PHP avvia lo sviluppo della correzione coordinata;
• 19 ottobre: Ubuntu ha già il pacchetto corretto pronto, prima ancora dell’annuncio (è la data di compilazione che ho visto sulla mia VPS);
• 20 ottobre: preavviso pubblico di PHP, con il rilascio fissato per il 21 ottobre alle 14:00 UTC, cioè le 16:00 in Italia;
• 21 ottobre: escono le versioni corrette, circa due mesi dopo la segnalazione.

Il rovescio della medaglia è che, appena si sa che esiste una falla così grave, in tanti si mettono a cercarla. PHP lo sapeva: nel preavviso si riservava di anticipare il rilascio se i dettagli fossero diventati pubblici o fossero comparsi attacchi.

Questa volta è successo proprio questo. I dettagli tecnici sono trapelati prima del rilascio previsto, e dalle ricostruzioni che ho fatto finora, quando sono uscite le patch i primi tentativi di attacco erano già partiti. In questo caso il preavviso ha avuto un prezzo, anche se ha limitato i danni.

Una volta uscita la correzione, i pacchetti delle distribuzioni sono arrivati in fretta: qualcuno mi ha scritto che alle 6 di sera aveva già aggiornato tutti i suoi pacchetti su Debian.

Perché falle come PHP2Shell saranno sempre di più?

PHP2Shell è stata trovata con l’aiuto dell’intelligenza artificiale. Molti analisti hanno usato GPT-5.6 Sol per trovarla, e Wiz racconta di aver usato anche Gemini. La falla è emersa dentro Patch the Planet, il programma di OpenAI per la sicurezza del software open source: lo ha scritto Greg Brockman, presidente di OpenAI.

Dentro Patch the Planet, secondo Trail of Bits che lo gestisce con OpenAI, già nella prima settimana erano state trovate centinaia di vulnerabilità in altri software. I modelli AI ormai sono capaci di trovare falle in software che usiamo da anni, e lo fanno sempre più spesso.

Per questo falle come PHP2Shell ne vedremo molte di più. Se hai un sito, sapere chi aggiorna il tuo PHP e come verificarlo ti farà comodo anche la prossima volta.