PHP2Shell: la vulnerabilità critica di PHP e cosa fare

Il 20 ottobre 2026 il team di sicurezza di PHP ha annunciato un aggiornamento urgente per due vulnerabilità critiche, e il 21 ottobre ha pubblicato le correzioni. Le due falle, soprannominate «PHP2Shell», permettono a chiunque di eseguire codice su un server web senza credenziali. PHP fa funzionare circa sette siti su dieci tra quelli di cui si conosce la tecnologia, compresi tutti quelli realizzati con WordPress, Joomla, Drupal e Magento.

Se sei nostro cliente puoi stare tranquillo: abbiamo già aggiornato PHP a una versione sicura per tutti i nostri clienti. Non devi fare nulla. Se il tuo sito è gestito da altri, qui sotto trovi cosa controllare.

Cosa è successo

• 17 ottobre. Amazon registra un primo tentativo di attacco sui suoi server esca (honeypot), quattro giorni prima che le vulnerabilità diventino pubbliche.
• 20 ottobre. Gli identificativi delle due vulnerabilità, CVE-2026-109618 e CVE-2026-109619, circolano in rete prima del previsto. Il team di PHP annuncia le correzioni per il giorno dopo, con un giorno di anticipo sul programma.
• 21 ottobre. Escono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Le distribuzioni Linux avevano ricevuto le correzioni in anticipo. Nelle stesse ore Amazon e Cloudflare segnalano i primi attacchi.

Perché è così grave

Entrambe le vulnerabilità hanno un punteggio di gravità di 9,2 su 10 (CVSS 4.0) e tre caratteristiche che raramente si trovano insieme:

• Non serve un accesso. Basta una richiesta al sito, senza login né password.
• Il difetto è in PHP, non nel sito. Avere WordPress, Joomla e i plugin aggiornati non protegge, perché il problema è nel linguaggio su cui girano. I ricercatori hanno dimostrato l'attacco su installazioni di WordPress, Drupal, Joomla e Magento.
• Riguarda ogni configurazione. Il team di PHP considera a rischio tutte le installazioni che servono pagine web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il rischio è massimo con mod_php, dove l'attacco può partire prima ancora che venga eseguito il codice del sito.

In termini tecnici, la prima vulnerabilità (CVE-2026-109618) nasce da come PHP gestisce l'esaurimento della memoria: un errore nel momento sbagliato lascia i dati della richiesta inizializzati a metà, e la pulizia finale li tratta come validi. La seconda (CVE-2026-109619) lascia in giro dati di una richiesta dopo che la loro memoria è stata liberata, e la richiesta successiva servita dallo stesso processo può riusarli. In entrambi i casi chi attacca riesce a eseguire codice con i permessi del server web.

Al momento del rilascio il team di PHP non aveva trovato exploit funzionanti in circolazione. Amazon però parla già di sfruttamento su larga scala, e diversi ricercatori hanno riprodotto gli attacchi in modo indipendente: qualsiasi sito non aggiornato va considerato a rischio.

Quali versioni sono sicure

• PHP 8.5: dalla 8.5.12.
• PHP 8.4: dalla 8.4.27.
• PHP 8.3: dalla 8.3.36.
• PHP 8.2: dalla 8.2.35. Il supporto della 8.2 però finisce il 31 dicembre 2026, quindi conviene già pianificare il passaggio a una versione più recente.
• PHP 8.1, 8.0 e 7.4: non ricevono più aggiornamenti ufficiali. Data la gravità, il team di PHP ha pubblicato le correzioni come codice sorgente, e alcuni fornitori le distribuiscono in pacchetti aggiornati. È una soluzione d'emergenza: la strada giusta è passare a una versione supportata.
• PHP 7.3 e precedenti: nessuna correzione. Le versioni colpite risalgono fino a PHP 5.4, quindi un sito così datato va aggiornato subito.

Su alcune distribuzioni Linux la correzione arriva in un pacchetto che mantiene il vecchio numero di versione. Se il numero che vedi non è in questa lista, chiedi al tuo hosting se la correzione è già installata.

Cosa fare se il tuo sito non è gestito da noi

1. Controlla la versione di PHP. La trovi nel pannello dell'hosting. In WordPress è in Strumenti → Salute del sito → Info → Server, in Joomla in Sistema → Informazioni di sistema.
2. Chiedi al tuo hosting se ha aggiornato, e quando. Su un hosting condiviso l'aggiornamento spetta al provider, non a te.
3. Non affidarti a plugin o frammenti di codice «anti PHP2Shell». La falla è nel linguaggio e un plugin non può correggerla: l'unica soluzione completa è aggiornare PHP.
4. Cerca segni di intrusione dal 17 ottobre in poi: utenti amministratori che non conosci, file PHP sconosciuti (per esempio nella cartella dei caricamenti), pagine modificate, errori 500 ripetuti. Se trovi qualcosa, considera il server compromesso: aggiornalo, ripristina un backup pulito e cambia tutte le password e le chiavi che il sito conosce (database, FTP, amministratori, servizi esterni).

Se gestisci tu il server

Se non puoi aggiornare subito, il team di PHP indica alcune misure che riducono il rischio senza eliminarlo: impostare memory_limit a -1 e session.upload_progress.enabled a 0 a livello di server (php.ini o pool di PHP-FPM; ini_set() e .user.ini arrivano troppo tardi), su PHP 8.5 anche fatal_error_backtraces a 0, abbassare post_max_size e riavviare tutti i processi PHP. Anche le regole firewall che Cloudflare ha attivato per tutti i suoi piani coprono solo gli attacchi già noti. Sono tamponi: l'installazione resta vulnerabile finché non viene aggiornata.

Questa volta aggiornare WordPress e i plugin non bastava: la falla era nel linguaggio su cui girano. Un sito sicuro ha bisogno di qualcuno che si occupi anche del server.

Come lavoriamo noi

Gli aggiornamenti di sicurezza del server sono compresi nel nostro hosting gestito: chi ci affida il sito non deve seguire i bollettini di sicurezza né ricordarsi di intervenire. Se il tuo sito è ospitato altrove e non sai quale versione di PHP usa, scrivici: verifichiamo insieme se è esposto e cosa serve per metterlo al sicuro.

Articolo aggiornato al 22 ottobre 2026. La situazione è in evoluzione: per i dettagli tecnici fa fede l'avviso di sicurezza ufficiale di PHP.