Il rilascio coordinato di PHP per CVE-2026-109618 e CVE-2026-109619 era previsto per le 14:00 UTC del 21 ottobre. Nella telemetria del nostro Next-Gen WAF, gli strumenti che portavano il nome del bug eseguivano scansioni già più di nove ore prima. Al momento del rilascio, più di 100 IP di origine avevano utilizzato strumenti con il nome PHP2Shell, identificati da più di due dozzine di nomi diversi. Uno di questi strumenti era un kit di exploit con il numero della CVE nel proprio User-Agent.

Questo post descrive le caratteristiche di quel traffico iniziale, come distinguere il vero traffico PHP2Shell da quello di due campagne simili attive nello stesso periodo e cosa fare per le applicazioni della tua azienda che utilizzano PHP.

Anatomia dei bug

PHP2Shell è il soprannome di due vulnerabilità critiche di PHP. Entrambe hanno un punteggio CVSS di 9,2 e possono consentire l’esecuzione di codice da remoto senza autenticazione:

• CVE-2026-109618: una condizione di esaurimento della memoria può interrompere PHP quando i dati interni della richiesta sono stati predisposti solo in parte; la successiva procedura di pulizia della richiesta considera quindi affidabili quei dati danneggiati.

• CVE-2026-109619: lo stato interno può persistere oltre la memoria che lo ospita e una richiesta successiva sullo stesso worker lo recupera.

Per chi cerca di rilevare PHP2shell, è importante sapere che non esiste una stringa nel payload con cui cercare una corrispondenza. L’exploit si basa su una condizione: far fallire la richiesta proprio nel momento sbagliato. 

Secondo PHP, tutte le installazioni che gestiscono richieste web sono a rischio, incluse quelle che usano PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed. PHP attribuisce a mod_php il livello di rischio più alto. 

I rilasci che includono la correzione sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35. PHP 8.1 e le versioni precedenti non ricevono correzioni upstream.

La cronologia

Come si è svolta la divulgazione e quando sono comparsi gli strumenti per PHP2shell. Tutti gli orari sono in UTC. Gli eventi relativi alla divulgazione sono descritti nel resoconto post mortem della PHP Foundation e negli avvisi di sicurezza di GitHub.

Gli identificativi delle CVE relative a PHP2shell (2026-109618 & 109619) sono trapelati senza dettagli tecnici e strumenti denominati PHP2shell sono comparsi nella nostra telemetria circa otto ore dopo il video dell’exploit. Il primo strumento identificato per nome e il primo kit di exploit che abbiamo osservato sono comparsi entrambi prima del rilascio anticipato delle immagini con patch. Non faremo ipotesi su cosa abbia portato alla comparsa di un determinato strumento, ma al momento del rilascio coordinato le scansioni erano già in pieno svolgimento.

Il pagliaio

Dal primo strumento con PHP2shell nel nome fino a mezzogiorno del 22 ottobre, abbiamo memorizzato circa 250.000 richieste inviate da strumenti con PHP2shell nel nome, provenienti da circa 3.200 indirizzi IP pubblici.

Naturalmente, non tutti gli scanner operano con intenti di attacco. Circa un terzo di quel traffico si presenta come attività difensiva: "verifica autorizzata dell’esposizione", "verifica dello stato delle patch", "senza exploit". Molte organizzazioni stavano controllando i propri ambienti, ed è una buona cosa. Le etichette autoattribuite sono dichiarazioni non comprovate, ma sono coerenti con ciò che fanno quelle richieste: piccole verifiche innocue.

Richieste provenienti da strumenti con PHP2shell nel nome, per tipo di strumento (dal 21 ottobre alle 03:59 UTC a mezzogiorno del 22 ottobre, valori arrotondati). 

Il resto è un quadro variegato, e tutto è successo in fretta. Uno strumento per l’inventario delle versioni di PHP è passato dalla versione 4.0 alla 7.2 in circa undici ore.

Gli strumenti che eseguono iterazioni così rapide rendono obsolete nel giro di un giorno le firme basate sulle stringhe User-Agent.

Gli aghi

Finora, il modo più affidabile per distinguere il traffico di exploit reale da tutto il resto è stata la stringa di delimitazione multipart. Ogni kit di exploit che abbiamo individuato utilizza un delimitatore fisso o che segue uno schema ricorrente nell’intestazione Content-Type. In questo modo abbiamo identificato oltre dieci kit candidati, cinque dei quali direttamente riconducibili a PHP2shell per nome, User-Agent o comportamento.

Il kit più diffuso si presenta così:

• POST /index.php (o /), User-Agent php2shell-109618

• Content-Type: multipart/form-data; boundary=B7kQpoc618

• un corpo multipart di dimensioni fisse e un insieme minimo di intestazioni

Si rivolge inoltre ai bersagli usando direttamente l’indirizzo IP anziché il nome host e invia una o due richieste per host. Si tratta quindi di una scansione su larga scala dello spazio degli indirizzi IP, non di una campagna mirata a siti specifici. 

Le dimensioni del corpo delle richieste variano notevolmente da un kit all’altro, quindi non affidarti soltanto alle soglie dimensionali per individuare questo traffico.

Due casi simili da escludere per primi

Se stai cercando PHP2shell nei tuoi log, altre due campagne ostacoleranno la ricerca.

React2Shell (CVE-2025-55182). Due firme associate a PHP2shell che stanno circolando sono le richieste multipart con codifica chunked prive dell’intestazione Content-Length e i corpi delle richieste riempiti con lunghe sequenze della lettera A. Nell’ora esaminata, React2Shell rappresentava rispettivamente il 98,6% e il 99,9% delle corrispondenze con queste firme. Già il giorno prima del rilascio, le corrispondenze con la firma relativa al riempimento erano quasi interamente riconducibili a React2Shell. React2Shell invia richieste a ogni percorso, inclusi /xmlrpc.php e /wp-login.php. L’elemento più semplice per distinguerli è l’intestazione di richiesta Next-Action, utilizzata dalle Server Actions di Next.js ma mai da PHP.

Percentuale di ciascuna firma "PHP2shell" in circolazione che corrisponde effettivamente a React2Shell, misurata tramite l’intestazione Next-Action nelle richieste post agli endpoint PHP, il 21 ottobre dalle 21:00 alle 22:00 UTC. Nella stessa ora del giorno precedente al rilascio, la firma basata sul padding corrispondeva già per il 99,7% a React2Shell.

wp2shell. Si tratta di una vulnerabilità completamente diversa: una vulnerabilità di esecuzione di codice da remoto senza autenticazione nel core di WordPress, divulgata nel luglio 2026. Il relativo kit invia corpi multipart di grandi dimensioni a index.php di WordPress, con un delimitatore che inizia con ----wp2shell. Era attivo ben prima che PHP2shell fosse reso pubblico, quindi includerlo nel conteggio creerebbe una storia di php2shell "precedente alla divulgazione" che non ha riscontro nei fatti.

Una lezione generale che si può trarre da entrambi: una firma basata sulla struttura della richiesta descrive un tipo di richiesta, non un hacker. Confronta i dati con un riferimento precedente alla divulgazione e suddividi ogni aumento in base a un’intestazione identificativa o a un delimitatore prima di attribuirlo.

Cosa puoi e non puoi vedere dall’edge

I tentativi di exploit sono visibili ai bordi della rete, ma non è possibile sapere se hanno avuto successo. PHP2shell funziona causando l’arresto anomalo o l’alterazione di un processo PHP, quindi dall’esterno un tentativo riuscito può apparire identico a uno fallito. Se ritieni di essere stato preso di mira, la conferma si trova sul server di origine:

• Log degli errori di PHP-FPM

• Log degli errori di Apache che mostrano arresti anomali dei processi worker (ad esempio, voci AH00051 "child pid … exit signal")

• Connessioni in uscita impreviste dai processi worker PHP, poiché una shell con connessione inversa genera traffico in uscita dal server di origine

Cosa ci dice PHP2Shell sull’IA

L’IA aiuta certamente a individuare le vulnerabilità, e lo fa molto più rapidamente che in passato. Nel giro di circa un giorno dalla comparsa del primo strumento, abbiamo osservato decine di strumenti identificati per nome provenienti da circa 3.200 indirizzi IP, e uno strumento è passato dalla versione 4.0 alla 7.2 in circa undici ore. 

Non possiamo sapere con certezza se qualcuno di essi sia stato scritto con l’aiuto dell’IA. Ciò che osserviamo è che il traffico in sé non presenta nulla di insolito: i kit inviano un corpo multipart fisso direttamente agli indirizzi IP, con una o due richieste per host, da infrastrutture VPN e di hosting dello stesso tipo di quelle alla base della maggior parte delle scansioni. Indipendentemente dal grado di supporto dell’IA, osserviamo un panorama delle minacce sempre più ampio e in più rapida evoluzione.

E finora, la difesa continua a essere soprattutto una questione di persone. I responsabili della difesa hanno controllato i propri sistemi e classificato il traffico. Gli analisti alla ricerca di minacce hanno condiviso firme che si sono rivelate riferite quasi interamente a un’altra campagna. L’applicazione delle patch, la definizione dei valori di riferimento e l’analisi dei log del server di origine restano attività svolte in gran parte dalle persone, anche con il supporto dell’IA, e richiedono che siano le persone a pianificare le difese a più livelli più adatte e a collocarle nei punti giusti.

Cosa fare ora

1. Applica le patch. Esegui l’aggiornamento a 8.5.12, 8.4.27, 8.3.36 o 8.2.35 oppure al pacchetto con la patch della tua distribuzione. Se utilizzi la versione 8.1 o una precedente, rivolgiti al distributore del pacchetto per i backport oppure esegui l’upgrade.

2. Non inseguire false piste. User-Agent, indirizzo IP e dimensioni del corpo delle richieste possono tutti portarti fuori strada durante la ricerca delle minacce. Il vero indizio è nella stringa del delimitatore multipart.

3. Escludi React2Shell e wp2shell prima di conteggiare qualsiasi attività come PHP2shell.

4. Fai attenzione alle liste di blocco degli indirizzi IP. Diversi indirizzi IP presenti nelle liste che circolano per questa vulnerabilità sono indirizzi di uscita di VPN o Tor, oppure indirizzi residenziali e mobili che trasportano traffico ordinario. Bloccarli danneggia gli utenti reali.

5. Clienti del WAF Next-Gen di Fastly: per le applicazioni protette da Next-Gen WAF, attiva il segnale che copre sia CVE-2026-109618 sia CVE-2026-109619. È una regola basata su un modello, specifica per queste CVE, che funge da patch virtuale e rileva gli indizi strutturali dei tentativi di sfruttamento.
   Per maggiori dettagli, consulta il post di Fastly sulla protezione proattiva.
   

Nota: consigliamo inoltre di prendere in considerazione l’opzione “Automatic Common Vulnerability and Exposure Virtual Patching” in “Workspace Configurazione”, mostrata di seguito:

Indicatori

Come abbiamo effettuato le misurazioni

Questi dati provengono dalla telemetria delle richieste del WAF Next-Gen di Fastly tra il 20 e il 22 ottobre 2026. La cronologia della divulgazione si basa sul resoconto post mortem della PHP Foundation e sui registri degli avvisi di sicurezza di GitHub. I conteggi rappresentano limiti inferiori: possiamo riportare solo le richieste rilevate e registrate dal nostro web application firewall e alcuni dati a livello di intestazione provengono da ore campione corrispondenti, anziché da giornate intere.

Per informazioni più aggiornate, leggi Protezione proattiva di Fastly contro PHP2Shell e le vulnerabilità critiche RCE di PHP CVE-2026-109618 e CVE-2026-109619.