PHP2Shell è il nome attribuito a due vulnerabilità critiche nel motore PHP, CVE-2026-109618 e CVE-2026-109619, entrambe classificate CVSS 4.0 9,2/10. Il 21 ottobre 2026 il team PHP ha distribuito aggiornamenti straordinari perché, in determinate condizioni, un aggressore non autenticato può sfruttare errori nella gestione della memoria per eseguire codice sul server. Il problema è nel runtime PHP, non in un particolare plugin, tema o CMS.

La notizia ha attirato attenzione anche per il ruolo dell'intelligenza artificiale nella ricerca: Calif ha identificato una falla con GPT-5.6 Sol nell'iniziativa Patch the Planet, mentre Wiz ha scoperto e segnalato indipendentemente entrambe le vulnerabilità, usando strumenti AI e ricerca umana. È un caso concreto di come i modelli avanzati stiano cambiando i tempi della scoperta e della verifica dei bug.

L'urgenza, per chi amministra infrastrutture, è immediata: occorre aggiornare PHP, non soltanto WordPress o i suoi plugin.

In questo articolo

Come funzionano le vulnerabilità

La differenza rispetto a molti bug di sicurezza web è la posizione in cui interviene l'attacco. PHP esamina e prepara i dati di una richiesta HTTP prima di eseguire il codice applicativo. Se un difetto riguarda quella fase, le verifiche di login, i middleware e le protezioni scritte nell'applicazione possono non avere alcuna possibilità di fermarlo.

CVE-2026-109618: corruzione di memoria durante l'esaurimento delle risorse

La prima vulnerabilità riguarda la gestione di condizioni out of memory (OOM). Se un'allocazione fallisce mentre PHP sta inizializzando le strutture interne di una richiesta, il processo può lasciare dati in uno stato incompleto. Durante la pulizia successiva, il motore può interpretare quei dati invalidi come strutture valide, arrivando alla corruzione della memoria.

I ricercatori di Datadog Security Labs hanno riprodotto l'esecuzione remota di codice tramite una richiesta HTTP POST non autenticata contro PHP 8.5.11. Nella loro dimostrazione, il codice dello script PHP non veniva neppure raggiunto: il comando veniva eseguito durante la pulizia della richiesta fallita.

Questo chiarisce il limite di una difesa fondata unicamente sulla validazione dei parametri dentro l'applicazione. Il punto vulnerabile è precedente.

CVE-2026-109619: stato globale obsoleto tra richieste

La seconda falla riguarda riferimenti interni che sopravvivono alla liberazione della memoria a cui puntavano. Un worker PHP può gestire più richieste nel corso della propria vita; in condizioni particolari, una richiesta successiva può riutilizzare uno stato non più valido prima che l'inizializzazione normale lo ripristini.

Il risultato è un potenziale accesso a memoria già liberata, con possibili conseguenze sulla riservatezza dei dati e sull'esecuzione di codice. L'advisory ufficiale descrive la causa e i percorsi di mitigazione temporanea, ma sottolinea che soltanto l'aggiornamento completo elimina il rischio.

In entrambi i casi, l'effetto concreto dipende dall'architettura e dai privilegi del processo compromesso. Eseguire codice come utente del servizio web è già una violazione grave, ma non equivale automaticamente a ottenere privilegi di root.

Quanto è esposto il web

Secondo W3Techs, al 21 ottobre 2026 PHP è utilizzato dal 69,3% dei siti di cui è noto il linguaggio server-side. Il dato è stato spesso tradotto nel titolo secondo cui il 70% del web sarebbe vulnerabile.

Questa interpretazione è imprecisa. La quota di utilizzo di PHP misura quanto il linguaggio sia diffuso, non quanti server abbiano configurazioni sfruttabili né quanti siti siano stati compromessi. Per stimare l'esposizione concreta bisogna identificare la versione installata, l'eventuale presenza di patch applicate dal fornitore e il percorso attraverso cui le richieste arrivano all'interprete.

L'avviso PHP indica come interessati i server che elaborano richieste web con PHP, comprese installazioni PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Il rischio viene considerato particolarmente elevato per mod_php, dove è stato dimostrato un exploit che si attiva prima dell'esecuzione del codice dell'applicazione.

WordPress, Drupal, Joomla, Magento e i siti custom in PHP condividono lo stesso punto: il problema non dipende dal CMS. Aggiornare un plugin o il tema non corregge una vulnerabilità del runtime sottostante.

Chi ha scoperto le falle e quale ruolo ha avuto l'AI

La ricostruzione ufficiale di OpenAI attribuisce a Calif l'identificazione di una falla con l'assistenza di GPT-5.6 Sol nel programma Patch the Planet. Wiz Research ha individuato indipendentemente entrambe le vulnerabilità e ha comunicato i risultati ai manutentori PHP il 24 agosto 2026.

Nel proprio resoconto, Wiz cita l'utilizzo di Wiz Atlas, Gemini 4 Argon e GPT-5.6 Sol. Il modello Gemini 4 Argon avrebbe dato un contributo particolarmente significativo durante la ricerca e la verifica. Il lavoro ha incluso la realizzazione di prove tecniche contro applicazioni reali basate su Drupal e WordPress, oltre alla collaborazione con i manutentori per la correzione.

Parlare semplicemente di una falla «scoperta dall'AI» elimina quindi una parte essenziale del processo: ipotesi, verifica sperimentale, divulgazione responsabile, sviluppo delle patch, test e distribuzione hanno richiesto persone e organizzazioni differenti. Il coordinamento ha coinvolto il progetto PHP, Calif, Wiz, OpenAI, Cloudflare e altri soggetti.

Il cambiamento è comunque sostanziale. Difetti di memoria presenti nel codice da molti anni, che in passato avrebbero richiesto lunghissime attività di ricerca, possono diventare più accessibili grazie a modelli in grado di esaminare grandi porzioni di codice e assistere nell'analisi dei percorsi di esecuzione. Questa accelerazione favorisce i difensori, ma può ridurre anche il tempo necessario a un attaccante per sviluppare un exploit dopo la divulgazione.

Versioni PHP corrette

Il 21 ottobre 2026 sono state pubblicate queste release di sicurezza:

Ramo PHP Versione corretta
PHP 8.5 8.5.12
PHP 8.4 8.4.27
PHP 8.3 8.3.36
PHP 8.2 8.2.35

Le release precedenti dei rami interessati non contengono le correzioni ufficiali. PHP 8.5.11, per esempio, è precedente all'aggiornamento urgente e non va considerata sicura rispetto a PHP2Shell.

PHP 8.1 e i rami più vecchi non sono più supportati dal progetto. Per l'emergenza il team di sicurezza ha comunque reso disponibili backport sorgente minimi per PHP 7.4, 8.0 e 8.1, mentre alcune distribuzioni Linux e fornitori LTS possono distribuire pacchetti corretti mantenendo il numero di versione del ramo.

Questo introduce una distinzione operativa importante: una stringa di versione da sola non dimostra sempre la presenza o l'assenza della patch. I pacchetti delle distribuzioni possono includere fix retroportati. Occorre controllare l'advisory e il changelog del fornitore.

Come verificare l'esposizione

Il primo controllo è identificare quali istanze di PHP servono davvero i siti pubblici. Su una macchina possono convivere diverse versioni PHP, container e pool PHP-FPM; il comando eseguito nella shell può non corrispondere all'interprete usato dal web server.

Linux: verifiche iniziali senza modifiche

php -v
command -v php
ps -eo pid,user,args | grep -E '[p]hp-fpm|[a]pache2|[h]ttpd|[l]sphp'

Il primo comando mostra la versione della CLI. Il terzo aiuta a identificare i processi associati ai servizi web, ma non basta a verificare che ogni pool o virtual host utilizzi una versione corretta.

Se il server usa pacchetti Debian o Ubuntu, è utile controllare i pacchetti installati e gli aggiornamenti disponibili:

dpkg-query -W 'php*' 2>/dev/null
apt-cache policy php8.2-fpm php8.3-fpm php8.4-fpm php8.5-fpm

Non tutti i nomi dei pacchetti sono necessariamente presenti. Su altre distribuzioni si utilizzano i rispettivi package manager e advisory di sicurezza.

Per le applicazioni containerizzate, la verifica deve riguardare anche l'immagine da cui il processo PHP è stato avviato. Aggiornare il solo sistema host non modifica un container basato su un'immagine vulnerabile.

Hosting condiviso e WordPress

Su un hosting gestito, la versione PHP effettiva va controllata dal pannello del provider e, quando disponibile, dalle informazioni diagnostiche del sito. In WordPress la schermata Strumenti > Salute del sito > Informazioni > Server permette di vedere la versione PHP utilizzata dall'applicazione.

Quella schermata è un punto di partenza, non la prova definitiva che il fornitore abbia applicato tutte le patch. In caso di versioni con backport, chiedere all'hosting un riferimento all'avviso di sicurezza o al pacchetto corretto installato.

Non è necessario pubblicare pagine phpinfo() accessibili a chiunque per effettuare il controllo. Possono esporre informazioni sensibili sulla configurazione.

Aggiornamenti, mitigazioni e controlli

La soluzione completa è l'aggiornamento del runtime PHP. Le mitigazioni temporanee possono ridurre alcuni percorsi d'attacco, ma non eliminano le vulnerabilità.

La sequenza operativa per un intervento su un ambiente di produzione è la seguente.

  1. Individuare siti, virtual host, processi PHP-FPM e container pubblicamente raggiungibili; dare priorità ai servizi esposti a Internet.
  2. Verificare il metodo di distribuzione di PHP: pacchetti della distribuzione, pannello hosting, immagini container, build compilate manualmente o stack applicativo gestito.
  3. Eseguire i controlli di compatibilità e un backup prima di aggiornare la versione, soprattutto quando si passa da un ramo PHP non più supportato a uno recente.
  4. Applicare la release corretta oppure il pacchetto con backport confermato dal fornitore. Ricreare i container e assicurarsi che i nuovi worker PHP utilizzino effettivamente il runtime aggiornato.
  5. Verificare nuovamente la versione nel percorso web reale, testare le funzionalità principali e consultare i log per identificare errori inattesi.

L'advisory PHP elenca alcune mitigazioni provvisorie: limiti sulle dimensioni delle richieste, controlli a livello di proxy, disabilitazione di session.upload_progress.enabled e, per alcuni scenari di PHP 8.5, di fatal_error_backtraces. Sono interventi dipendenti dall'ambiente e richiedono che i worker vengano riavviati per applicare determinate impostazioni.

Il documento ufficiale propone anche memory_limit=-1 come possibile mitigazione di uno specifico percorso OOM, ma non è una modifica da effettuare indiscriminatamente: può alterare il comportamento delle applicazioni e la gestione delle risorse. L'advisory stesso chiarisce che rimangono altri percorsi di fallimento delle allocazioni.

Il ruolo di Cloudflare e dei WAF

Cloudflare ha comunicato di aver distribuito regole WAF specifiche, disponibili anche sui piani Free con WAF attivo, prima della divulgazione pubblica. L'azienda dichiara di aver osservato traffico d'attacco e tentativi di variare i payload per aggirare le protezioni.

Le regole del WAF aiutano a ridurre l'esposizione, ma non sostituiscono l'aggiornamento PHP. Occorre inoltre verificare che l'origine non sia raggiungibile direttamente aggirando il proxy.

Come verificare dopo l'intervento

Dopo il deploy non fermarsi all'assenza di errori visibili sul sito. La verifica concreta dovrebbe confermare almeno tre punti: il processo che serve le richieste usa la build corretta, le funzionalità applicative continuano a funzionare e non ci sono indizi di attacchi già avvenuti.

I ricercatori di Datadog indicano, tra gli elementi utili alla ricerca di possibili tentativi di sfruttamento, POST anomali o particolarmente grandi, errori di esaurimento memoria durante l'inizializzazione delle richieste e processi shell inattesi avviati da worker PHP. L'assenza di questi segnali non dimostra da sola che il server non sia stato compromesso.

Se emergono indicatori attendibili, conviene preservare log ed evidenze prima di intraprendere interventi di pulizia che potrebbero cancellarli.

Attacchi osservati e prospettive

Alla pubblicazione delle patch, il problema non era confinato a una dimostrazione accademica. Cloudflare ha riferito di aver osservato traffico di attacco indirizzato ai clienti e variazioni nei tentativi di aggirare il proprio WAF. Questo non permette di quantificare il numero di server compromessi, ma conferma che gli amministratori devono trattare la minaccia come operativa.

PHP2Shell mette in evidenza anche un problema più ampio dell'ecosistema software: la scoperta automatizzata delle vulnerabilità rischia di diventare più rapida della distribuzione delle correzioni. La disponibilità di una patch non coincide con il suo utilizzo su hosting condivisi, installazioni legacy, container o infrastrutture gestite da terzi.

La risposta coordinata tra ricerca AI, manutentori open source, fornitori cloud e operatori della sicurezza ha permesso di distribuire aggiornamenti e difese. Ora la parte decisiva è negli ambienti reali: censimento, patching e verifica dell'effettiva applicazione.

Per chi usa PHP in produzione, la domanda da porsi oggi non è se l'AI abbia effettivamente cambiato la cybersecurity. È più concreta: quale versione di PHP sta eseguendo il mio server e posso dimostrare che contiene la correzione?

Fonti e approfondimenti