Gli exploit PHP2Shell eseguono shell commands sugli honeypots
Lo sfruttamento di PHP2Shell sembra essere riuscito a eseguire shell commands su honeypots esposti a Internet, ossia sistemi esca utilizzati per osservare gli attacchi. Un ricercatore di Perplexity ha registrato comandi che usavano wget, curl e la PHP command-line interface per contattare 162.35.99[.]94 attraverso le porte 80 e 8080. Le richieste identificavano l'honeypot preso di mira e, in alcuni casi, l'account che eseguiva il comando. Non sono stati osservati file di secondo stadio scaricati, quindi lo scopo e le capacità di eventuali payload successivi rimangono sconosciuti.
L'attività riguarda CVE-2026-109618 e CVE-2026-109619, due vulnerabilità critiche di PHP che possono produrre remote code execution, consentendo a un aggressore di eseguire da remoto comandi sull'host interessato. Entrambe possono interessare le configurazioni PHP predefinite. Cloudflare ha segnalato milioni di tentativi di sfruttamento dopo la divulgazione pubblica, mentre Defused Cyber ha osservato probe contro honeypots Palo Alto Networks GlobalProtect provenienti da 204.76.203[.]7, un indirizzo associato allo sfruttamento di massa. Tali richieste includevano il marker p2s-rider del PHP session upload progress e un upload fittizio senza payload, un comportamento valutato come verifica della vulnerabilità e creazione di elenchi di obiettivi.
Datadog ha descritto il processo di sfruttamento come dipendente dall'esaurimento accuratamente controllato della memoria disponibile in una fase specifica e dall'individuazione di posizioni di memoria utilizzabili nonostante l'address space layout randomization (ASLR), una protezione che modifica la posizione dei dati in memoria. Durante l'elaborazione di una richiesta, PHP crea diverse copie del nome di un campo del form. Un aggressore può utilizzare un nome di dimensioni insolite per provocare un errore di allocazione mentre PHP lo copia in una hash table. La richiesta deve essere abbastanza piccola da venire accettata, ma strutturata in modo che la copia superi il limite di memoria configurato in PHP.
ReliaQuest ha riprodotto CVE-2026-109618 in un laboratorio controllato e ha pubblicato indicazioni per il rilevamento il 22 ottobre 2026. Il test ha prodotto una sequenza nei log di PHP, Apache e del sistema: una richiesta POST ha ricevuto un errore HTTP 500, PHP ha registrato l'esaurimento della memoria e una heap corruption, mentre il worker Apache che elaborava la richiesta è andato in crash. I team che gestiscono l'hosting possono utilizzare questa combinazione come potenziale segnale di allarme, anziché considerare un singolo errore del server una prova dello sfruttamento.
Nel frattempo, Unit 42 di Palo Alto Networks ha ritirato una precedente conclusione secondo cui un attacco contro un'agenzia governativa europea sarebbe iniziato attraverso le vulnerabilità PHP2Shell. Unit 42 ha affermato che l'attacco si è verificato nel contesto di un'applicazione PHP vulnerabile, ma non ha potuto confermare che una delle due CVE specifiche abbia fornito l'accesso iniziale. Questa correzione è importante perché il comportamento successivo alla compromissione rimane degno di nota, ma non può essere presentato come un'intrusione PHP2Shell confermata.
In quell'incidente, Unit 42 ha osservato l'accesso agli hash delle password e ai segreti di multi-factor authentication entro due ore, insieme a un tunnel NTLM relay verso Active Directory, il sistema Microsoft utilizzato per gestire le identità e le autorizzazioni di un'organizzazione. L'aggressore ha inoltre tentato di ottenere privilegi Domain Admin. I comandi esaminavano i dati di autenticazione, interrogavano il domain controller tramite richieste LDAP anonime e cercavano host interni, gruppi privilegiati, utenti interattivi e collegamenti tra DNS e Active Directory. Le sezioni di output utilizzavano delimitatori coerenti come ==SHELLUSER== e ==PASSWD==, che Unit 42 ha valutato come una formattazione leggibile dalle macchine destinata a un sistema di agentic AI capace di pianificare ed eseguire gruppi di attività.
Separatamente, CYFIRMA ha segnalato uno scanning PHP2Shell a basso volume proveniente da 21 nodi compromessi e diretto contro 216 host senza patch o con mitigazioni parziali. I sistemi identificati si trovavano negli Stati Uniti, in Giappone, Corea del Sud, Thailandia, Indonesia, Australia, Taiwan, India, Singapore, Emirati Arabi Uniti, Arabia Saudita e Unione europea. Comprendevano servizi governativi, finanziari, logistici, aeronautici, manifatturieri e per le transazioni online. CYFIRMA ha riferito che i nodi venivano sostituiti o abbandonati quando comparivano blocchi o rate limit, riducendo la probabilità che semplici soglie basate sul volume rilevassero la campagna.
CYFIRMA ha attribuito questo scanning, con un livello di confidenza moderato, a un operatore di lingua coreana associato all'ecosistema Lazarus Group. La valutazione si basava su attività all'interno di una rete di anonimato I2P chiusa, su infrastrutture precedentemente collegate allo sfruttamento di risorse web, su caratteristiche linguistiche e sulla storia del gruppo nel compromettere server PHP e WordPress per installare web shells o usarli per traffico command-and-control. CYFIRMA ha affermato che gli operatori discutevano la definizione delle priorità degli obiettivi e adattavano exploit pubblici, ma il suo resoconto descriveva attività di scanning e preparazione, non lo sfruttamento confermato dei 216 host elencati.
Anche una terza vulnerabilità, CVE-2026-115560, è stata divulgata dalla PHP Foundation. La remote code execution richiede una combinazione insolita di comportamento dell'applicazione e configurazione: session.serialize_handler deve inizialmente utilizzare php_binary o php_serialize, l'applicazione deve cambiarlo in php tramite ini_set() prima di chiamare session_start() e il session upload progress deve rimanere abilitato. Le applicazioni che non modificano il serialization handler durante l'esecuzione possono lasciare abilitato l'upload progress. La PHP Foundation prevede che il problema venga risolto attraverso il normale ciclo di release.
Xint ha pubblicato uno scanner per individuare l'esposizione a PHP2Shell e afferma che la remote code execution può interessare qualsiasi script PHP, indipendentemente dall'applicazione, oltre alle applicazioni che eseguono la decodifica tramite funzioni come session_start() e unserialize(). Le misurazioni su scala Internet di Bitsight hanno individuato quasi 37 milioni di sistemi esposti pubblicamente che eseguono PHP o software correlato, con le maggiori concentrazioni negli Stati Uniti, in Germania, Francia, Paesi Bassi e Giappone. Poiché queste vulnerabilità si trovano nel runtime PHP stesso, modificare il codice dell'applicazione, installare l'aggiornamento di un plugin o affidarsi a un web application firewall non elimina la debolezza sottostante. PHP deve essere aggiornato sull'host.
I proprietari dei siti web dovrebbero pertanto verificare il runtime PHP utilizzato da ogni sito e applicazione, anziché limitarsi ad aggiornare WordPress o le sue estensioni. Per i proprietari che desiderano affidare a terzi la gestione, AEU Hosting offre managed WordPress hosting protetto end to end. Sia che PHP venga gestito autonomamente sia che venga fornito da un provider di hosting, le priorità immediate sono aggiornarlo ed esaminare i log alla ricerca della sequenza di errori e dei pattern di probing documentati dai ricercatori.