PHP2Shell: l’AI scopre falle critiche in PHP, attacchi già iniziati

Un’intelligenza artificiale ha contribuito a scoprire due falle nel cuore di PHP, il linguaggio su cui si basano milioni di siti e applicazioni web. Le vulnerabilità, riunite sotto il nome PHP2Shell, permettono in determinate condizioni di eseguire comandi su un server senza possedere credenziali di accesso. Il progetto PHP ha distribuito le correzioni il 21 ottobre 2026, ma la corsa è già cominciata: Amazon Threat Intelligence ha individuato un tentativo di sfruttamento risalente al 17 ottobre, quattro giorni prima della divulgazione pubblica.

La portata potenziale dell’emergenza dipende dalla diffusione di PHP. Secondo W3Techs, il 21 ottobre il linguaggio era impiegato dal 69,3% dei siti dei quali è identificabile la tecnologia server. Questa percentuale descrive la presenza di PHP sul web: i server realmente esposti dipendono dalla versione installata, dalla configurazione, dalle protezioni presenti e dagli aggiornamenti già eseguiti. Per chi gestisce portali aziendali, e-commerce o applicazioni rivolte ai clienti, la verifica riguarda l’infrastruttura su cui gira il sito, oltre al software visibile agli utenti.

PHP2Shell, due vulnerabilità nel motore dei siti aziendali

Il bollettino di sicurezza pubblicato dal progetto PHP identifica i problemi con le sigle CVE-2026-109618 e CVE-2026-109619. Entrambi hanno un punteggio di gravità CVSS 4.0 pari a 9,2 su 10. Un attacco riuscito può consentire di leggere informazioni sensibili dalla memoria del processo PHP o di eseguire codice con i privilegi del processo che serve le pagine web.

Le conseguenze per un’impresa: furto di password, chiavi API e token, modifica del contenuto di un sito, sottrazione di dati, interruzione dei servizi o impiego del server compromesso per colpire altri sistemi. I ricercatori di Wiz Research hanno dimostrato lo sfruttamento delle vulnerabilità in installazioni di WordPress, Drupal e Joomla. Calif documenta prove anche su altri prodotti e applicazioni PHP, fra cui Magento e Nextcloud.

La caratteristica decisiva è la posizione del difetto. PHP2Shell colpisce il motore che interpreta il codice PHP, prima o durante l’elaborazione delle richieste web. Di conseguenza, anche un’applicazione con codice e plugin aggiornati può restare vulnerabile se il server continua a utilizzare una versione di PHP priva delle correzioni.

Come l’AI ha individuato una debolezza rimasta aperta per anni

La ricerca è partita da un problema antico. Già nel 2004 lo specialista Stefan Esser aveva studiato attacchi legati alla gestione della memoria di PHP; nel 2020 era stata segnalata un’anomalia che poteva provocare l’esaurimento della memoria e nel 2024 un audit di Quarkslab e OSTIF aveva individuato una debolezza correlata, senza dimostrarne lo sfruttamento. Nell’agosto 2026 Ryan Austin, ricercatore di Calif, ha ricostruito una catena di errori sfruttabile da remoto, trasformando una pista conosciuta in un rischio operativo grave.

Il lavoro di Calif è stato svolto nell’ambito del programma Patch the Planet di OpenAI, che ha messo a disposizione il modello GPT-5.6 Sol e sostenuto il coordinamento fra ricercatori, manutentori del software e fornitori di sicurezza. Austin ha indirizzato il modello verso i punti più promettenti del codice, facendo analizzare sequenze di operazioni e condizioni d’errore che potevano lasciare la memoria del programma in uno stato incoerente.

In parallelo, un gruppo di Wiz ha raggiunto risultati indipendenti, utilizzando Wiz Atlas, Gemini 4 Argon e GPT-5.6 Sol. Google Cloud attribuisce a Gemini 4 Argon un contributo all’individuazione delle falle, alla costruzione degli exploit, alle verifiche delle patch e alle tecniche di rilevamento. I due percorsi mostrano il nuovo ruolo dei modelli avanzati: assistere gli specialisti nell’esplorazione di codice complesso, nel collegamento di difetti distinti e nei test ripetuti su configurazioni differenti.

Nel resoconto tecnico Austin sottolinea anche il peso dell’esperienza umana: è stata la conoscenza di una vecchia classe di attacchi a orientare l’indagine. L’AI ha accelerato la verifica delle ipotesi e l’esplorazione delle varianti, mentre il ricercatore ha scelto le domande e interpretato i risultati. Il cambiamento riguarda soprattutto il tempo e le competenze necessari per rendere sfruttabile un difetto che in passato poteva apparire troppo complesso.

Come funziona PHP2Shell e perché l’impatto è così ampio

Le due vulnerabilità hanno un’origine comune: quando il server incontra un errore grave, per esempio l’esaurimento della memoria durante l’elaborazione di una richiesta, PHP può lasciare dati interni incompleti oppure riutilizzare riferimenti a memoria già liberata. Una richiesta successiva può incontrare quelle informazioni alterate. I ricercatori hanno dimostrato che, combinando più passaggi, è possibile arrivare all’esecuzione di codice da remoto.

Il rischio coinvolge diverse modalità di esecuzione di PHP, fra cui Apache con mod_php, PHP-FPM, php-cgi e altri ambienti. Il gruppo di sicurezza PHP considera particolarmente esposta la configurazione mod_php, nella quale è stato dimostrato un attacco possibile prima ancora dell’avvio del codice dell’applicazione. Per PHP-FPM i percorsi tecnici e le condizioni di sfruttamento differiscono, ma il progetto raccomanda l’aggiornamento di tutti gli ambienti PHP che servono richieste web.

Gli attacchi cominciano prima della pubblicazione delle patch

La sequenza degli eventi è uno degli aspetti più importanti del caso. Amazon ha analizzato i dati della propria rete di sistemi-esca MadPot e ha identificato un tentativo di sfruttamento il 17 ottobre. Il 21 ottobre, prima e dopo il rilascio delle correzioni, i sensori hanno registrato ulteriori tentativi da infrastrutture differenti. Amazon parla ormai di sfruttamento diffuso in rete, ma le sue osservazioni su sistemi-esca non dimostrano da sole che tutti quei tentativi abbiano compromesso server reali.

Anche Cloudflare ha segnalato traffico ostile e tentativi di modificare le richieste per superare i filtri. L’azienda aveva attivato regole protettive per i clienti con web application firewall dalle 03:02 UTC del 21 ottobre, circa nove ore prima della divulgazione pubblica. La comunicazione coordinata delle falle avrebbe dovuto concedere tempo ai manutentori per distribuire aggiornamenti; una fuga di informazioni del 20 ottobre ha anticipato il calendario.

Il risultato è una corsa asimmetrica: chi difende deve individuare tutte le installazioni esposte, verificare la compatibilità degli aggiornamenti e distribuirli; chi attacca può concentrarsi su una sola configurazione debole. Il fatto che le prime attività ostili precedano l’annuncio pubblico complica anche la ricostruzione delle compromissioni: la data della patch non coincide con il possibile inizio degli attacchi.

Patch PHP2Shell: quali versioni aggiornare subito

Le versioni corrette sono disponibili dal 21 ottobre. La misura prioritaria è aggiornare l’interprete PHP effettivamente utilizzato dal sito e riavviare i processi coinvolti, verificando poi la versione attiva. Le release rilasciate direttamente dal progetto sono queste:

Le versioni PHP che correggono PHP2Shell

Fonte: PHP Security Team, bollettino del 21 ottobre 2026. Per le distribuzioni Linux conta anche la versione corretta del pacchetto fornito dal vendor.

Chi utilizza un servizio di hosting gestito deve chiedere al fornitore quale runtime PHP sia in esecuzione e se la correzione sia stata applicata a tutte le istanze che servono il sito. Le imprese che gestiscono server, container e applicazioni cloud devono controllare anche immagini e ambienti replicati, aggiornare le distribuzioni e ridistribuire i servizi. Aggiornare WordPress, i temi o i plugin resta una normale attività di sicurezza, ma interviene su un livello diverso da quello colpito da PHP2Shell.

Per i rami PHP più vecchi le possibilità dipendono dal supporto contrattuale: Ubuntu, per esempio, ha pubblicato pacchetti corretti anche per alcune versioni storiche ancora coperte dai propri programmi di manutenzione. La verifica va quindi condotta sul pacchetto specifico del sistema operativo, perché il suo numero di versione può restare inferiore a quello della release ufficiale PHP pur includendo la correzione retroportata.

WAF e analisi dei log: come verificare se un sito è già stato colpito

Il progetto PHP precisa che la patch è l’unica correzione completa. Filtri WAF, restrizioni alle richieste e modifiche temporanee alla configurazione possono ridurre le opportunità di sfruttamento, ma coprono percorsi di attacco specifici. Anche Cloudflare invita i clienti protetti dalle proprie regole ad aggiornare PHP: l’azione del firewall guadagna tempo, mentre l’aggiornamento corregge il difetto nel motore.

Per i responsabili IT e cybersecurity la verifica dovrebbe comprendere i log almeno dal 17 ottobre, alla luce delle osservazioni di Amazon: richieste anomale di caricamento dati, errori ripetuti di esaurimento della memoria, risposte HTTP 500 insolite, riavvii imprevisti dei processi PHP e comparsa di file o processi sconosciuti. Gli indicatori vanno analizzati nel contesto della specifica infrastruttura, evitando di interpretare ogni errore del server come prova di attacco.

Se emergono indizi concreti di compromissione, servono le normali procedure di incident response: isolare il sistema interessato, conservare i log e ricostruire gli accessi, controllare l’integrità dei file e valutare la revoca delle credenziali che potrebbero essere state esposte. L’aggiornamento interrompe lo sfruttamento della falla, mentre un’eventuale presenza ostile già installata richiede una bonifica separata.

Il collo di bottiglia: l’AI trova i bug, l’open source deve correggerli

Il caso mette in evidenza anche una fragilità organizzativa. In un bilancio pubblicato dalla PHP Foundation, i manutentori riconoscono che i primi indizi del problema erano emersi nell’audit del 2024. La correzione era rimasta sospesa fra soluzioni capaci di introdurre incompatibilità, rischi di blocco dei servizi o modifiche difficili da coordinare con le estensioni PHP. La Foundation attribuisce il ritardo anche a un processo decisionale debole e alla scarsità di sviluppatori con una conoscenza profonda del motore.

L’arrivo delle dimostrazioni di attacco nell’agosto 2026 ha trasformato il problema in una priorità assoluta. La Foundation segnala inoltre un nuovo carico di lavoro per chi riceve le segnalazioni: 15 vulnerabilità catalogate dal 1° luglio e oltre 100 rapporti risultati inesatti, duplicati o impossibili da riprodurre. I modelli aiutano a raggruppare e verificare le segnalazioni, ma la decisione su cosa correggere e come farlo resta agli ingegneri. Per le aziende che dipendono dall’open source, investire nella manutenzione delle componenti condivise diventa così una parte concreta della strategia di sicurezza.

Con PHP2Shell l’AI cambia l’economia della sicurezza informatica

Il significato di PHP2Shell va oltre l’aggiornamento urgente di un linguaggio. I modelli AI stanno riducendo il lavoro necessario per scoprire vulnerabilità, costruire prove di sfruttamento e adattarle ad ambienti diversi. Sul versante difensivo permettono di individuare falle rimaste nascoste per anni e di testare correzioni più rapidamente. Sul versante offensivo possono accorciare il tempo fra la pubblicazione di una patch e la produzione di strumenti d’attacco.

OpenAI definisce questo vantaggio temporaneo dei difensori Defender’s Window e, attraverso Patch the Planet, propone un modello di collaborazione fra laboratori di AI, manutentori open source, fornitori cloud e autorità. La società ha inoltre annunciato un miliardo di dollari di accesso agevolato al sistema Daybreak per organizzazioni impegnate a proteggere servizi essenziali. Le rilevazioni di Amazon mostrano però quanto possa essere breve la finestra utile quando la scoperta della falla avviene anche fuori dai gruppi che stanno preparando le patch.

Per le imprese cambia una metrica di gestione: il tempo di correzione delle vulnerabilità critiche esposte su Internet va misurato in ore, come raccomanda Amazon, invece di confidare nei cicli ordinari di aggiornamento settimanali o mensili. A fare la differenza saranno l’inventario delle dipendenze software, la capacità di distribuire rapidamente una correzione, il monitoraggio delle anomalie e il sostegno alla manutenzione dei componenti open source da cui dipendono servizi digitali e processi aziendali.