PHP2Shell è il nome dato a una coppia di vulnerabilità di sicurezza estremamente gravi, corrette dal PHP Security Team con un rilascio d'emergenza il 21 ottobre 2026. Le due falle, registrate come CVE-2026-109618 e CVE-2026-109619, hanno ricevuto entrambe un punteggio di gravità di 9.2 su 10 sulla scala CVSS e permettono a un attaccante di eseguire codice malevolo da remoto (in gergo RCE, Remote Code Execution) su tutti i server web con un'installazione vulnerabile di PHP, senza bisogno di credenziali e senza alcuna interazione da parte dell'amministratore.

A differenza di altri attacchi che colpiscono le applicazioni (come la SQL Injection) o il core di un CMS (come gli attacchi brute force o DDoS tramite l’XML-RPC di WordPress), PHP2Shell colpisce il runtime di PHP, cioè il motore interno del linguaggio di programmazione. Se si pensa che questo linguaggio fa funzionare circa il 70% dei siti web nel mondo, non sorprende l'allarme delle compagnie di hosting, che da giorni stanno intasando le caselle email dei propri clienti, sollecitandoli affinché sostituiscano immediatamente le versioni vulnerabili con quelle corrette appena rilasciate:

Versione PHP	Vulnerabilità	Patch applicata
8.5	fino alla 8.5.11	8.5.12
8.4	fino alla 8.4.26	8.4.27
8.3	fino alla 8.3.35	8.3.36
8.2	fino alla 8.2.34	8.2.35 (fine supporto: 31/12/2026)
8.1 e precedenti	tutte	Nessuna release ufficiale: backport da hosting o fornitori LTS, migrazione consigliata

Il bug risiede nel meccanismo di gestione della memoria temporanea, ossia lo spazio usato da PHP per elaborare le richieste inviate dagli utenti. L'attaccante invia un payload, un contenuto malevolo costruito ad arte per imitare le strutture interne del runtime di PHP e per esaurire la memoria (out-of-memory) nel momento esatto in cui PHP sta preparando i propri dati, causandone l'interruzione. Nella fase di pulizia che chiude la richiesta (request cleanup), PHP tratta i dati dell'attaccante come validi e devia dal proprio flusso di esecuzione originario, finendo per eseguire il comando nascosto nel payload: ad esempio, aprire una shell o scaricare un malware.

Le falle sono state individuate ad agosto da due team di ricercatori esterni (Calif e Wiz), che utilizzando diversi modelli di IA come GPT-5.6 Sol di OpenAI e Gemini di Google, sono riusciti in tempi brevissimi a completare un lavoro di analisi che, secondo Wiz, in passato avrebbe richiesto mesi ad un intero team di esperti. La cosa più sconcertante, secondo Greg Brockman di OpenAI, è che il bug era presente in PHP da ben 14 anni. Una sua variante era già emersa nel 2024 ma, senza un modo concreto per sfruttarla non era stata ritenuta grave, e la correzione si era arenata per mesi: la stessa PHP Foundation ha ammesso il ritardo, definendolo un “fallimento strutturale” dovuto sia al processo decisionale sia alla mancanza di risorse.

L'IA, quindi - continua Wiz - non ha tanto scoperto qualcosa di invisibile, quanto dimostrato che quel problema sottovalutato era concretamente sfruttabile, rendendo la correzione una priorità assoluta. Se poi pensiamo che Calif non ha utilizzato versioni speciali o riservate, bensì lo stesso GPT-5.6 Sol accessibile a chiunque, è facile capire perché l’IA possa rivelarsi – come ha avvertito la stessa OpenAI – un’arma a doppio taglio: i modelli che hanno aiutato i ricercatori a scovare le falle potrebbero aiutare allo stesso modo gli attaccanti a trovare vulnerabilità ancora sconosciute e a costruire rapidamente degli exploit.

Questa evoluzione cosi rapida sta costringendo l'industria a passare da una difesa "reattiva" a una difesa guidata dall'IA in tempo reale, in cui i sistemi di protezione devono essere veloci quanto, o più di, chi sferra gli attacchi. Anthropic, ad esempio, ha scelto di non rendere pubblico il suo modello più capace, Claude Mythos Preview, affidandolo soltanto a un gruppo ristretto di organizzazioni proprio per usarlo in difesa. È un altro approccio allo stesso problema: dare ai difensori un consistente vantaggio di tempo, per arrivare alle falle prima dei malintenzionati.

Ma a che serve avere un vantaggio sugli attaccanti, se il giorno dopo la maggior parte dei siti era ancora vulnerabile? Secondo un’analisi di Melurna, 24 ore dopo il rilascio della patch, tra i siti che hanno dichiarato la versione installata, il 33% era su un ramo supportato ma non aveva ancora applicato la correzione, mentre il 44% girava su PHP fuori supporto (8.1 e precedenti), con la 7.4 che, al 20 ottobre, era la seconda versione più diffusa (20%). La sicurezza reale, quindi, non dipende più solo da chi trova per primo le falle, ma anche dal tempo che si impiega a chiuderle e a colmare quel “debito tecnico” accumulato negli anni, fatto di installazioni ferme a versioni ormai obsolete.

Un consiglio? Se il vostro sito è su un hosting condiviso o gestito, verificate che il provider abbia già aggiornato PHP alla versione corretta. Se invece avete un VPS o un server dedicato, anche se acquistato presso un provider, l’aggiornamento spetta quasi sempre a voi: installate la patch al più presto. Se siete ancora su PHP 8.1 o precedente, pianificate il passaggio a una versione supportata, possibilmente successiva alla 8.2, visto che il suo supporto terminerà il 31 dicembre 2026.

Approfondimenti

PHP.net – Security advisory: Critical remote code execution vulnerabilities
The PHP Foundation – Today’s PHP Security Release, and How We’re Strengthening PHP Security
Wiz – PHP2Shell
Calif – PHP2Shell
OpenAI – Divulgazione coordinata di vulnerabilità critiche
Anthropic – Project Glasswing
Melurna – PHP2Shell Patch Status: Who Patched, Who’s Still Exposed
TechTarget – PHP2Shell explained: Timeline of the global vulnerability crisis