PHP2Shell: la vulnerabilità di PHP che riguarda (quasi) ogni sito, e cosa fare subito

Il 20 ottobre 2026 sono state rese pubbliche due vulnerabilità del runtime di PHP, battezzate PHP2Shell (CVE-2026-109618 e CVE-2026-109619). Permettono a chiunque, senza password, di eseguire comandi sul server che ospita un sito. Poiché il difetto è in PHP stesso e non in una singola applicazione, riguarda WordPress, PrestaShop, Joomla, Laravel e qualsiasi sito PHP non aggiornato.

In sintesi

Gravità 9,2 su 10 (CVSS v4.0), nessuna autenticazione richiesta, versioni corrette disponibili dal 21 ottobre. La risposta è aggiornare PHP e riavviare i servizi; chi è su versioni fuori supporto deve pianificare una migrazione. Aggiornare chiude la porta ma non caccia chi è già entrato: il controllo di eventuali intrusioni fa parte del lavoro.

Cosa è successo

• Scoperta. Le falle sono state individuate ad agosto 2026 durante un audit del codice sorgente di PHP, con una divulgazione coordinata in programma.
• 17 ottobre. Amazon Threat Intelligence segnala un primo tentativo di sfruttamento, prima ancora dell’annuncio.
• 20 ottobre. La notizia trapela online e un video di dimostrazione viene diffuso per errore: l’annuncio avviene di fatto in anticipo.
• 21 ottobre. PHP rilascia le versioni corrette, poco prima dell’orario annunciato. Chi ha pubblicato i pacchetti in anticipo ha di fatto mostrato agli attaccanti cosa fosse cambiato.

Sullo sfruttamento reale le fonti non concordano: alcuni operatori di sicurezza parlano di attacchi già in corso, altri enti dicono di non averne ancora osservati. Il consiglio pratico non cambia: non conviene scommettere sul fatto che “a noi non succederà”.

Come funziona, in breve

Sono due errori di gestione della memoria nel core di PHP, con la stessa radice: quando PHP incontra un errore fatale, per esempio la memoria esaurita, interrompe l’esecuzione in modo brusco e la pulizia dello stato della richiesta resta incompleta.

• CVE-2026-109618. Un errore di memoria esaurita può fermare PHP mentre i dati della richiesta (per esempio un upload) sono inizializzati solo in parte; la pulizia successiva li tratta come validi.
• CVE-2026-109619. Dello stato globale può sopravvivere alla fine di una richiesta anche dopo che la sua memoria è stata liberata, e una richiesta successiva sullo stesso processo legge dati ormai invalidi.

Il punto che conta per chi gestisce un sito: il problema nasce nella fase in cui PHP elabora la richiesta, prima che giri il codice del sito. Per questo non basta non avere una pagina di upload per sentirsi al sicuro.

Cosa può fare un attaccante

Un attacco riuscito esegue comandi con i permessi dell’utente web. Su un sito o un e-commerce basta per:

• leggere i file di configurazione e le credenziali del database, e scaricare clienti, ordini e hash delle password;
• inserire uno script nel checkout che ruba i dati delle carte, un danno silenzioso che può durare mesi;
• creare un utente amministratore nascosto o una webshell che resta anche dopo l’aggiornamento di PHP;
• modificare prezzi, coordinate di pagamento e contenuti, o reindirizzare i visitatori;
• inviare spam e phishing dal server, finendo in blacklist con conseguenze sulla posta;
• cifrare i file a scopo di riscatto, o usare il server come base per colpire altri siti sullo stesso hosting.

Non si parte da amministratore del sistema, ma con permessi troppo larghi o container configurati male il passo successivo è spesso breve. E se si accertasse un accesso a dati personali, in Europa scatta l’obbligo di notifica al Garante entro 72 ore e di avviso agli interessati.

Chi è esposto e quali versioni sono corrette

Sono interessate le versioni di PHP dalla 5.4 alla 8.5 precedenti ai rilasci del 21 ottobre. Le versioni corrette sono:

• 8.5.12, 8.4.27, 8.3.36, 8.2.35: aggiornare.
• 8.1 e precedenti (7.x, 5.x): nessun rilascio ufficiale. Esistono patch sorgente per 7.4, 8.0 e 8.1 ma nessun pacchetto pronto, quindi servono migrazione o isolamento. Alcuni fornitori (ad esempio cPanel e CloudLinux) hanno rilasciato backport propri: una versione “vecchia” può essere già corretta, ma va verificato con chi gestisce il server.

L’aggiornamento riguarda ogni punto in cui gira PHP: il server web (mod_php o PHP-FPM), la riga di comando e, soprattutto, le immagini Docker, che contengono la propria copia di PHP e non si aggiornano con il sistema operativo dell’host.

Cosa fare subito

1. Fare l’inventario. Per ogni server e ogni container, la versione di PHP realmente in uso, non solo quella della riga di comando: php -v, il modulo caricato da Apache o il servizio PHP-FPM, e docker exec <container> php -v.
2. Aggiornare alla versione corretta del proprio ramo con il gestore pacchetti.
3. Riavviare Apache o PHP-FPM. I processi già in esecuzione continuano a usare il vecchio PHP finché non vengono riavviati.
4. Ricostruire i container con un’immagine aggiornata (docker compose build --pull) e verificare la versione dentro il container.
5. Rimuovere le versioni di PHP non più necessarie, in particolare quelle fuori supporto.
6. Attivare gli aggiornamenti automatici di sicurezza, includendo l’eventuale repository terzo da cui arriva PHP.

Se non si può aggiornare subito

I mantenitori di PHP hanno precisato che nessuna contromisura temporanea è completa: l’unica soluzione sicura è aggiornare. Nel frattempo si può ridurre il rischio, guadagnando tempo:

• un firewall applicativo (WAF) davanti al sito, con le regole del provider o di un CDN;
• limiti sulla dimensione del corpo delle richieste (post_max_size, LimitRequestBody);
• area di amministrazione accessibile solo da indirizzi IP autorizzati;
• in mancanza di alternative, sito offline finché non è sistemato: è l’indicazione data anche da alcune autorità per i sistemi che non si possono né aggiornare né proteggere.

Come verificare se si è già stati colpiti

Gli attacchi sono iniziati prima della patch, quindi conviene controllare, anche se i segnali sono spesso discreti.

• Processi anomali. Shell, curl, wget o nc avviati come figli del web server o di PHP sono il segnale più tipico (ps auxf).
• File modificati di recente. File .php cambiati dal 17 ottobre in poi, soprattutto in cartelle di upload, immagini, cache e moduli, dove non dovrebbero esserci file eseguibili.
• Codice sospetto. Funzioni come eval(base64_decode, gzinflate(, shell_exec( in file che non le usano. Nelle librerie ci sono falsi positivi legittimi: contano soprattutto i file nel codice del sito.
• Log del web server. Richieste POST multipart/form-data seguite da errori 4xx o 5xx, e messaggi di memoria esaurita o segfault nei log di errore.
• Persistenza. Nuovi utenti amministratori nel CMS, cron job sconosciuti, chiavi SSH aggiunte, porte in ascolto non riconosciute.

Se emergono tracce di compromissione: isolare il sito, ripristinare da un backup precedente al 17 ottobre, cambiare tutte le credenziali (database, amministratori, chiavi API) e valutare gli obblighi di notifica.

Quando non si può semplicemente aggiornare

Il caso più delicato è quello dei siti costruiti su versioni vecchie: un e-commerce PrestaShop 1.6 su PHP 7.4, per esempio. PHP 7.4 non riceve più patch e PrestaShop 1.6 non funziona con le versioni di PHP ancora supportate. Qui un WAF come quello di Cloudflare è un cerotto temporaneo: riduce il rischio ma non lo elimina, perché chi raggiunge direttamente il server può comunque aggirarlo.

La soluzione definitiva è la migrazione a una versione supportata del CMS e di PHP. Il timore più comune è perdere il posizionamento sui motori di ricerca, e si evita con metodo:

1. mappare gli URL attuali prima di toccare qualsiasi cosa (Search Console, scansione del sito);
2. mantenere gli stessi indirizzi dove possibile;
3. impostare redirect 301 dal vecchio al nuovo indirizzo per ogni pagina che cambia;
4. testare tutto su un ambiente di prova (moduli, tema, checkout, pagamenti) prima della produzione;
5. monitorare Search Console nelle settimane successive e correggere gli errori.

I cali di posizionamento dopo una migrazione nascono quasi sempre da indirizzi cambiati senza redirect, non dall’aggiornamento in sé.

Il punto per chi compra IT

Episodi come questo misurano un fornitore meglio di qualsiasi presentazione commerciale. Se chi gestisce il tuo sistema risponde in poche ore con versioni, piano e date, ha processo. Se la risposta è vaga, o scopri che il sito gira su un PHP non supportato da anni, hai trovato un debito che prima o poi presenta il conto. Le domande minime da fare oggi: quale versione di PHP gira in produzione (il numero, per ogni ambiente), se è una versione corretta o un backport, quando verrà aggiornata e da chi, se esiste un backup recente e ripristinabile, e se qualcuno ha controllato i segnali di compromissione.

Se gestisci siti, server o e-commerce e vuoi una verifica indipendente della tua infrastruttura o un piano di migrazione, con i percorsi di Advisory IT e AI & Cybersecurity Governance ne parliamo.

Fonti consultate: Qualys, watchTowr, Akamai, Armis, Imperva, Recorded Future, CNBC e la voce Wikipedia “PHP2Shell”. I dettagli sullo sfruttamento erano ancora in evoluzione alla data di pubblicazione.