In un angolo silenzioso della rete, dove giacciono trappole costruite apposta per attirare chi attacca, è finalmente apparsa la prova che una minaccia lungamente temuta sulla carta era ormai reale. Due falle gemelle del linguaggio PHP, che alimenta gran parte del web, sono state sfruttate pochi giorni dopo la loro correzione, a conferma di una vecchia regola: la distanza tra il rilascio di una riparazione e il primo colpo sferrato da chi cerca di approfittarne è spesso più breve di quanto gli amministratori sperino. Il risultato resta circoscritto a una configurazione scelta con cura, ma basta
PHP2Shell sfruttata in attacchi reali: confermata RCE su Apache con mod_php e PHP 8.4.26
Non più un rischio teorico: un honeypot ha visto l'attacco riuscire
Perché questo caso conta più dei tentativi precedenti?
Perché prima c'erano scansioni ed exploit che non funzionavano. Qui un honeypot ha registrato un'esecuzione di codice riuscita su PHP 8.4.26 con Apache e mod_php.
Ma teniamo i piedi per terra: è un caso documentato su un honeypot, non una stima di quanti server siano stati violati.
Cosa ha convinto i ricercatori?
Il dump di cookie da 800 KiB conteneva un indirizzo di funzione ricavato con gli offset dell'exploit pubblico, poi riusato nel payload successivo. Karimi parla di divulgazione di memoria utilizzabile.
E conferma Marcus Hutchins di Expel, che però è un secondo parere sull'analisi, non una seconda prova indipendente.
Quanto è affidabile l'exploit, allora?
Non lo sappiamo. Karimi stesso dice che il profilo a singolo worker era volutamente favorevole e che non misura altri worker, build o applicazioni.
Per questo la CISA, per ora, ha diffuso solo una regola SIGMA e non ha classificato le falle come sfruttate attivamente.
E la nuova CVE-2026-115560?
Non ha ancora una patch ed è sfruttabile solo con una combinazione inusuale di configurazione e codice. Si consiglia session.upload_progress.enabled=0.
The Pulse
- Un honeypot gestito da Perplexity ha registrato un'esecuzione di codice da remoto riuscita su un server Apache con PHP 8.4.26, pochi giorni dopo il rilascio delle patch.
- Per settimane gli attacchi contro PHP2Shell erano andati a vuoto, e ora il primo successo confermato rompe quella quiete e costringe gli amministratori a rivedere le proprie priorità.
- L'exploit ha funzionato solo in una configurazione mod_php a singolo worker, un contesto favorevole che non dice quanto sia affidabile in ambienti reali più complessi.
- Ricercatori indipendenti come Marcus Hutchins di Expel hanno confermato l'episodio, mentre la CISA ha diffuso una regola di detection ma non ha ancora classificato le falle come sfruttate.
- Una seconda vulnerabilità, CVE-2026-115560, resta senza patch: la mitigazione indicata è disattivare session.upload_progress.enabled, in attesa di una correzione.
In un angolo silenzioso della rete, dove giacciono trappole costruite apposta per attirare chi attacca, è finalmente apparsa la prova che una minaccia lungamente temuta sulla carta era ormai reale. Due falle gemelle del linguaggio PHP, che alimenta gran parte del web, sono state sfruttate pochi giorni dopo la loro correzione, a conferma di una vecchia regola: la distanza tra il rilascio di una riparazione e il primo colpo sferrato da chi cerca di approfittarne è spesso più breve di quanto gli amministratori sperino. Il risultato resta circoscritto a una configurazione scelta con cura, ma basta a ricordare che ogni server non aggiornato è una porta che qualcuno sta già osservando.
Negli honeypot gestiti da Adel Karimi, responsabile detection and response di Perplexity, è comparsa una prova che cambia il quadro. Un'installazione Apache con mod_php basata su PHP 8.4.26 è stata compromessa con successo, e l'esecuzione di codice da remoto è stata registrata pochi giorni dopo il rilascio delle patch per PHP2Shell, le due vulnerabilità critiche CVE-2026-109618 e CVE-2026-109619.
Fino a quel momento gli attacchi osservati erano falliti. Il sistema colpito ha restituito un dump di cookie decodificato di 800 KiB, e al suo interno Karimi ha trovato un indirizzo di funzione ricavato dagli offset di un exploit pubblico, riutilizzato poi in un payload successivo. Secondo la sua valutazione, non si tratta di un semplice crash, ma di una RCE confermata con fuga di memoria utilizzabile.
Karimi ha però precisato il limite della scoperta: la catena è stata dimostrata su un profilo a singolo worker, scelto apposta per essere favorevole. Marcus Hutchins di Expel, che da giorni seguiva segnalazioni non verificate, ha parlato della conferma di più alta qualità vista finora in the wild.
La cronologia mostra un'escalation graduale. Amazon Threat Intelligence aveva notato attacchi mirati quattro giorni prima delle patch, mentre altri soggetti come Cloudflare, Hadrian, watchTowr, Previdian e Patchstack avevano registrato soltanto tentativi falliti. Le patch sono arrivate il 21 ottobre, con dettagli e proof-of-concept già in circolazione, che il team di PHP aveva definito non funzionanti.
La posta in gioco è enorme, perché PHP alimenta circa il 70% dei siti web. Intanto la CISA ha pubblicato una regola SIGMA per individuare i tentativi, senza però dichiarare le falle attivamente sfruttate. Resta aperto il fronte di CVE-2026-115560, ancora senza patch, per cui il team di sicurezza di PHP raccomanda di impostare session.upload_progress.enabled=0 fino alla correzione.
Nei honeypot gestiti da Adel Karimi, responsabile detection and response di Perplexity, è comparsa la prova che il rischio attorno a PHP2Shell non era più teorico. Un'installazione Apache con mod_php basata su PHP 8.4.26 è stata compromessa con successo: un'esecuzione di codice da remoto riuscita, registrata pochi giorni dopo il rilascio delle patch.
PHP2Shell è il nome con cui sono note due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619. Fino a questo episodio, gli attacchi osservati erano andati a vuoto. Il sistema compromesso ha restituito un dump di cookie decodificato da 800 KiB. Al suo interno Karimi ha trovato un indirizzo di funzione ricavato con gli offset dell'exploit pubblico, poi riutilizzato nel payload dell'esecuzione successiva. La sua valutazione è stata netta: si tratta di RCE confermata con divulgazione di memoria utilizzabile, non di un semplice crash seguito da un processo sospetto.
Karimi ha però fissato un limite alla portata della scoperta. La catena d'attacco è stata dimostrata su un profilo mod_php a singolo worker, scelto perché intenzionalmente favorevole. Il risultato, quindi, non misura l'affidabilità dell'exploit con altri conteggi di worker, altre build di PHP o altre applicazioni.
Le sue conclusioni sono state confermate da Marcus Hutchins, ricercatore di minacce di Expel, che da giorni seguiva segnalazioni non verificate di attacchi PHP2Shell riusciti. Hutchins ha parlato della conferma di più alta qualità finora vista di sfruttamento in the wild, accompagnata da una ricostruzione tecnica approfondita.
La cronologia mostra un'escalation graduale. Amazon Threat Intelligence aveva individuato attacchi mirati quattro giorni prima del rilascio delle patch, ma secondo il team Threat Research and Cyber Engineering di Dataminr l'attività si limitava a scansioni, fingerprinting ed exploit non funzionanti, senza compromissioni accertate. Anche Cloudflare, Hadrian, watchTowr, Previdian e Patchstack avevano rilevato tentativi prima della divulgazione pubblica, tutti falliti.
Le patch sono arrivate mercoledì 21 ottobre, un giorno dopo l'avviso agli amministratori di prepararsi. Nel frattempo, dettagli sulle falle, compresi gli identificativi CVE e le indicazioni di mitigazione date ad alcuni gestori di infrastrutture critiche, circolavano online insieme a proof-of-concept pubblici, che il team di PHP aveva definito tutti non funzionanti. Venerdì la CISA ha diffuso una regola di detection in formato SIGMA per individuare i tentativi di exploit, ma non ha ancora classificato le falle come sfruttate attivamente.
La posta in gioco è ampia: PHP alimenta circa il 70% dei siti web, con oltre 5,1 milioni di host esposti online e circa 3,8 milioni con almeno una porta aperta ad attacchi.
Resta aperto un secondo fronte. Venerdì il team di sicurezza di PHP ha pubblicato misure di mitigazione per un'altra vulnerabilità RCE, CVE-2026-115560, ancora senza patch e sfruttabile solo con una combinazione inusuale di configurazione e codice applicativo. Fino alla correzione, gli sviluppatori raccomandano di impostare session.upload_progress.enabled=0, la stessa misura già suggerita prima delle patch per PHP2Shell.
Notable Quotes
Questa è ormai RCE confermata con divulgazione di memoria utilizzabile, non un semplice crash seguito da un processo sospetto.— Adel Karimi, Perplexity
La conferma di più alta qualità finora vista di sfruttamento in the wild di php2shell.— Marcus Hutchins, Expel