PHP2Shell,milioni di siti Web a rischio e la disclosure diventa un caso

Ott 23, 2026 Redazione news Approfondimenti, Attacchi, Attacchi, In evidenza, News, RSS, Tecnologia, Vulnerabilità 0

Le falle CVE-2026-109618 e CVE-2026-109619 consentono, in determinate condizioni, l’esecuzione di codice da remoto senza autenticazione. Individuate attraverso una combinazione di ricerca tradizionale e strumenti di intelligenza artificiale, hanno richiesto un intervento coordinato su scala internazionale. Ma fughe di informazioni e pubblicazioni anticipate hanno complicato la gestione dell’emergenza.

Due vulnerabilità nel cuore di PHP, una diffusione potenzialmente enorme e una procedura di divulgazione coordinata compromessa proprio nelle ore precedenti al rilascio delle patch. È questa la vicenda di PHP2Shell, il nome con cui i ricercatori hanno identificato due falle critiche che interessano uno dei linguaggi di programmazione più utilizzati per realizzare siti Web e applicazioni online.

Le vulnerabilità, codificate CVE-2026-109618 e CVE-2026-109619, hanno entrambe ricevuto un punteggio CVSS 4.0 di 9,2 e, in determinate condizioni, possono consentire a un attaccante remoto, privo di credenziali, di eseguire codice sui server che utilizzano versioni vulnerabili di PHP.

Il 21 ottobre 2026 il progetto PHP ha pubblicato aggiornamenti straordinari per le versioni ancora supportate. La gravità della situazione ha portato anche a una presa di posizione congiunta della Commissione Europea, di ENISA, CERT-EU, Europol e della rete europea dei CSIRT, che hanno invitato le organizzazioni a intervenire immediatamente, dando priorità ai sistemi esposti su Internet.

Una vulnerabilità conosciuta dal 2024, ma sottovalutata

L’aspetto forse più interessante della vicenda riguarda la storia della prima vulnerabilità. Il problema alla base di CVE-2026-109618 era già emerso nel 2024, durante una verifica esterna della sicurezza del motore PHP.

All’epoca, tuttavia, il team di sviluppo non era riuscito a individuare una soluzione soddisfacente. Il difetto riguardava una parte particolarmente delicata del funzionamento interno del linguaggio e le possibili correzioni presentavano conseguenze difficili da valutare: incompatibilità con il software esistente, nuovi rischi di denial of service e potenziali problemi per le numerose estensioni sviluppate da terze parti.

Mancava inoltre una dimostrazione convincente che il problema potesse essere sfruttato per ottenere l’esecuzione di codice da remoto.

Il risultato fu uno stallo. Gli sviluppatori conoscevano il difetto, ma non avevano una prova della sua effettiva pericolosità né una correzione che considerassero sufficientemente sicura per l’intero ecosistema.

La situazione è cambiata nell’estate del 2026, quando nuovi strumenti di analisi del codice basati sull’intelligenza artificiale hanno contribuito a individuare percorsi di sfruttamento molto più pericolosi.

Secondo la ricostruzione pubblicata dalla PHP Foundation, il lavoro si è intensificato attraverso audit condotti con strumenti di Anthropic e OpenAI, oltre alle attività di ricercatori indipendenti e società specializzate.

L’11 agosto la scoperta che cambia la valutazione del rischio

Il passaggio decisivo avviene l’11 agosto 2026. Ryan A, ricercatore della società di sicurezza Calif, segnala al progetto PHP una possibilità di esecuzione arbitraria di codice riconducibile alla stessa causa del problema di gestione della memoria identificato nel 2024.

Nella stessa giornata, OpenAI segnala indipendentemente la medesima causa di fondo. Seguono ulteriori risultati da parte di Wiz, il 24 agosto, e nuovi vettori di attacco individuati da OpenAI il 18 settembre.

Il coinvolgimento dell’intelligenza artificiale non significa che i sistemi automatici abbiano gestito autonomamente l’intera ricerca. Il contributo dei modelli è stato integrato con il lavoro degli specialisti, che hanno verificato le segnalazioni, riprodotto gli attacchi e collaborato alla preparazione delle correzioni.

È però significativo che una vulnerabilità rimasta irrisolta per quasi due anni sia diventata una priorità assoluta dopo che gli strumenti di ricerca assistita dall’AI hanno contribuito a dimostrarne le conseguenze.

Da quel momento, secondo la PHP Foundation, la correzione del problema è diventata l’attività principale del team di sicurezza, con sviluppatori impegnati anche durante i fine settimana e nelle ore notturne.

La vicenda dimostra quanto stia cambiando il rapporto tra individuazione delle vulnerabilità e capacità di correggerle: l’AI può accelerare la scoperta di problemi complessi, ma non elimina le difficoltà tecniche e organizzative necessarie a distribuire una patch affidabile.

La disclosure doveva essere coordinata. Poi sono cominciate le fughe di notizie

Una volta confermata la gravità delle vulnerabilità, il progetto PHP ha organizzato una procedura di coordinated vulnerability disclosure, coinvolgendo ricercatori, distributori software, provider cloud e società di sicurezza.

L’obiettivo era rendere disponibili gli aggiornamenti contemporaneamente alla pubblicazione dei dettagli tecnici, evitando che gli attaccanti potessero utilizzare le informazioni prima che gli amministratori avessero la possibilità di proteggere i sistemi.

La pubblicazione era inizialmente prevista per il 22 ottobre alle 14:00 UTC.

Il piano comincia a complicarsi il 20 ottobre, intorno alle 15:00 UTC, quando i due identificativi CVE iniziano a circolare su forum e social network. Le informazioni diffuse riportano un punteggio CVSS di 10,0 e un orario di pubblicazione errato. Non contengono ancora dettagli tecnici sufficienti a spiegare lo sfruttamento delle falle.

Il progetto PHP decide comunque di anticipare l’annuncio pubblico, che viene diffuso alle 19:30 UTC, e di spostare il rilascio delle patch al 21 ottobre.

La scelta di non pubblicare immediatamente gli aggiornamenti ha una ragione operativa: i distributori stanno ancora preparando i pacchetti. Rilasciare i dettagli senza offrire contemporaneamente un percorso praticabile per aggiornare i sistemi avrebbe rischiato di aumentare l’esposizione degli utenti.

Il video pubblicato per errore

La situazione peggiora poche ore dopo. Intorno alle 20:00 UTC del 20 ottobre, Calif pubblica erroneamente un video che mostra il funzionamento di un proof of concept, ossia una dimostrazione pratica dello sfruttamento delle vulnerabilità. Il video viene rimosso, ma alcune copie cominciano a circolare online.

Secondo la PHP Foundation, la diffusione del materiale contribuisce ad accelerare lo sviluppo di ulteriori tentativi di exploit. Il team di sicurezza segue le dimostrazioni pubblicate nelle ore successive, senza tuttavia individuare exploit funzionanti tra quelli esaminati prima della disclosure ufficiale.

Non si tratta quindi di una pubblicazione deliberata dei dettagli tecnici da parte del progetto PHP, ma di un errore che contribuisce a compromettere la riservatezza delle informazioni condivise con i ricercatori.

Chainguard pubblica le immagini corrette prima della scadenza dell’embargo

L’episodio più controverso avviene la mattina del 21 ottobre, alle 07:41 UTC. Secondo la ricostruzione della PHP Foundation, Chainguard pubblica immagini container che contengono già le correzioni, oltre sei ore prima del rilascio coordinato.

Chainguard aveva ricevuto le patch in anticipo, come altri distributori, per consentire ai propri clienti di aggiornare tempestivamente i sistemi. La pubblicazione anticipata, però, rende possibile analizzare le differenze tra il codice vulnerabile e quello corretto.

È una situazione particolarmente delicata: attraverso il cosiddetto patch diffing, un attaccante può studiare le modifiche introdotte dalla correzione e utilizzarle per individuare il difetto originario.

La PHP Foundation ha accusato esplicitamente Chainguard di aver violato unilateralmente l’embargo, compromettendo settimane di coordinamento.

La vicenda evidenzia un problema strutturale delle disclosure che coinvolgono software estremamente diffuso: per preparare le difese bisogna condividere informazioni con molti soggetti, ma ogni ulteriore partecipante aumenta il rischio di pubblicazioni premature.

Il 21 ottobre, intorno alle 13:40 UTC, vengono infine rilasciate le versioni corrette di PHP e pubblicati i dettagli delle vulnerabilità.

La prima vulnerabilità: la gestione della memoria può consentire l’esecuzione di codice

La CVE-2026-109618 riguarda la gestione delle condizioni di esaurimento della memoria, indicate come out of memory o OOM. PHP impone normalmente limiti alla quantità di memoria utilizzabile da uno script. Quando una richiesta raggiunge quel limite, il motore deve interrompere l’operazione e liberare le risorse associate.

Il problema emerge quando l’esaurimento della memoria si verifica in un momento particolarmente delicato dell’elaborazione. In determinate circostanze, PHP può interrompere l’esecuzione lasciando alcune strutture interne solo parzialmente inizializzate. Successivamente, il motore può considerarle ancora valide, anche se la memoria alla quale fanno riferimento è stata liberata o riutilizzata.

È una forma di corruzione della memoria che può consentire a un attaccante di alterare il comportamento del processo. I ricercatori hanno dimostrato che, utilizzando particolari percorsi di elaborazione delle richieste HTTP, il difetto può essere sfruttato anche prima che venga eseguito il codice dell’applicazione.

Nel caso di Apache con mod_php, è stata dimostrata l’esecuzione di codice da remoto senza autenticazione utilizzando impostazioni predefinite. Sono stati confermati percorsi di sfruttamento anche in ambienti PHP-FPM, attraverso specifiche funzionalità applicative.

La conseguenza è importante: non è necessario che il sito Web contenga una vulnerabilità nel proprio codice PHP. Il problema si trova nel motore che interpreta ed esegue quel codice.

Wiz ha inoltre dimostrato che alcune varianti consentono di leggere porzioni della memoria dei processi PHP. Questo può esporre password, token di autenticazione, chiavi API e altre informazioni appartenenti anche a richieste differenti.

La seconda vulnerabilità: informazioni residue tra richieste diverse

La CVE-2026-109619 interessa un problema correlato, ma distinto: la conservazione di riferimenti a strutture interne che avrebbero dovuto essere eliminate dopo un errore fatale.

Quando un processo PHP gestisce una richiesta, utilizza diverse strutture per memorizzare informazioni sull’esecuzione. In determinate condizioni di errore, alcuni riferimenti possono rimanere presenti anche dopo che la memoria corrispondente è stata liberata.

Se lo stesso processo gestisce successivamente un’altra richiesta, può tentare di utilizzare quelle informazioni ormai obsolete.

Si crea così una condizione di use-after-free, nella quale il software accede a una porzione di memoria che non dovrebbe più considerare valida.

Le conseguenze possono andare dal crash del processo alla corruzione controllata della memoria, fino all’esecuzione arbitraria di codice.

I ricercatori hanno individuato anche un percorso di sfruttamento che coinvolge OPcache, il componente di PHP che conserva in memoria il codice già compilato per migliorare le prestazioni.

Un errore durante la gestione delle strutture condivise può produrre una type confusion, ossia una situazione nella quale il sistema interpreta una struttura di memoria come se contenesse un tipo di dato diverso da quello effettivo.

Wiz ha dimostrato la possibilità di utilizzare questi meccanismi per ottenere l’esecuzione di codice senza autenticazione in ambienti WordPress e Drupal.

Il problema, ancora una volta, riguarda il funzionamento interno di PHP e non una specifica vulnerabilità dei CMS utilizzati nelle dimostrazioni.

Perché PHP2Shell rappresenta un rischio così esteso

PHP è alla base di una parte considerevole dei siti Web e delle applicazioni aziendali. Viene utilizzato da piattaforme come WordPress, Drupal e Joomla, ma anche da gestionali, portali di commercio elettronico, applicazioni sviluppate internamente e numerosi servizi forniti da terze parti.

Secondo Wiz, le vulnerabilità interessano codice presente in versioni PHP risalenti a oltre un decennio fa, e almeno una delle falle riguarda release fino alla famiglia PHP 5.4.

Questo non significa che il 70% dei siti Internet sia automaticamente compromettibile: la possibilità di sfruttare le vulnerabilità dipende dalla versione di PHP, dalla configurazione del server e dal percorso di attacco disponibile.

Il rischio rimane comunque eccezionalmente ampio, perché una falla nel motore PHP può coinvolgere contemporaneamente applicazioni differenti, anche quando il loro codice è stato sviluppato seguendo correttamente le pratiche di sicurezza.

L’impatto potenziale comprende l’esecuzione di codice sul server, il furto di credenziali e informazioni riservate, la compromissione dei siti ospitati e l’utilizzo dell’infrastruttura per ulteriori attacchi.

Un altro elemento preoccupante è la possibilità di accedere alla memoria di richieste differenti. Nei sistemi che servono numerosi utenti, le informazioni recuperate potrebbero appartenere a sessioni diverse da quella controllata dall’attaccante.

Le dimostrazioni pubblicate da Wiz mostrano inoltre che la complessità tecnica non rappresenta più necessariamente una barriera efficace. I modelli AI utilizzati dai ricercatori hanno contribuito ad adattare gli exploit a configurazioni differenti, riducendo tempi e competenze necessari per alcune fasi della ricerca.

L’intelligenza artificiale ha quindi svolto un ruolo positivo nell’individuazione delle falle, ma le stesse capacità possono essere impiegate per accelerare lo sviluppo di strumenti offensivi.

Gli attacchi sono già cominciati?

La distinzione tra possibilità di sfruttamento, disponibilità di exploit e compromissioni effettivamente confermate è fondamentale.

Al momento della disclosure, la PHP Foundation dichiarava di non aver individuato exploit funzionanti tra i proof of concept che aveva esaminato durante la fase precedente al rilascio.

Questo non equivale a escludere l’esistenza di attacchi.

Cloudflare ha segnalato tentativi di sfruttamento e diversi gruppi di ricerca hanno successivamente pubblicato dimostrazioni funzionanti delle vulnerabilità. Le autorità di sicurezza considerano quindi il rischio di attacchi concreti particolarmente elevato.

Per gli amministratori è importante non confondere un tentativo di attacco con una compromissione riuscita: la presenza di traffico riconducibile a PHP2Shell richiede un’indagine, ma non dimostra automaticamente che il server sia stato violato.

Le versioni corrette e le misure di protezione

Il progetto PHP ha pubblicato il 21 ottobre quattro versioni che includono le correzioni:

Ramo PHP	Prima 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 versioni PHP 8.1 e precedenti non ricevono più aggiornamenti dal progetto PHP e richiedono quindi una migrazione verso un ramo supportato oppure una soluzione di sicurezza specifica fornita da un distributore che ne garantisca la manutenzione.

Per le aziende, la priorità è identificare tutte le installazioni PHP effettivamente in uso, comprese quelle integrate in prodotti di terze parti, container, ambienti cloud e sistemi meno visibili agli strumenti ordinari di inventario.

ENISA raccomanda di dare precedenza ai sistemi esposti su Internet e, quando non sia possibile applicare immediatamente le patch, di valutare l’isolamento delle applicazioni vulnerabili dalle reti pubbliche.

Le protezioni implementate dai provider di rete e dai Web Application Firewall possono ridurre il rischio di alcuni tentativi di sfruttamento, ma non rappresentano un’alternativa completa all’aggiornamento del motore PHP.

È inoltre opportuno verificare eventuali anomalie nei log e nel comportamento dei processi, soprattutto quando compaiono errori ripetuti legati alla memoria, risposte HTTP 500 insolite o riavvii anomali dei worker PHP.

Il vero problema è la (in)capacità dell’open source di reagire alla velocità dell’AI

PHP2Shell è destinato a diventare un caso di studio non soltanto per la gravità tecnica delle vulnerabilità, ma anche per le implicazioni organizzative della loro scoperta.

La PHP Foundation ha riconosciuto apertamente che il ritardo accumulato nella correzione del problema individuato nel 2024 è stato un fallimento strutturale, dovuto sia alle difficoltà del processo decisionale sia alla scarsità di risorse disponibili.

La stessa organizzazione ha spiegato che gli strumenti di analisi basati sull’AI stanno aumentando rapidamente il numero di segnalazioni ricevute. Dal primo luglio sono stati pubblicati 15 CVE, mentre oltre cento segnalazioni sono risultate non valide, duplicate o impossibili da riprodurre.

L’AI può contribuire a individuare e verificare i problemi, ma la scelta di una correzione compatibile con un ecosistema vastissimo richiede ancora sviluppatori esperti, test approfonditi e coordinamento tra numerosi soggetti.

La vicenda della disclosure dimostra inoltre quanto sia fragile l’equilibrio tra riservatezza e preparazione delle difese. Distribuire le patch in anticipo ai fornitori è indispensabile per proteggere milioni di sistemi, ma aumenta il numero di organizzazioni che devono rispettare l’embargo.

PHP2Shell mette quindi in evidenza due problemi destinati a diventare sempre più importanti: la velocità con cui l’intelligenza artificiale può trasformare difetti complessi in vulnerabilità sfruttabili e la difficoltà delle infrastrutture software globali di correggerli con la stessa rapidità.

Condividi l'articolo