PHP2Shell, attacchi riusciti: 35 shell eseguite su tre server PHP

🛡️ Executive Summary

• Adel Karimi documenta 35 esecuzioni di shell su tre honeypot PHP 8.4.26, attraverso richieste HTTP correlate ai processi Apache.
• Gli attacchi utilizzano una catena di corruzione della memoria e divulgazione di indirizzi per aggirare ASLR e ottenere esecuzione remota di comandi.
• La compromissione è dimostrata sui sistemi di test raggiunti dagli attaccanti, ma non costituisce prova di una campagna di compromissioni riuscite su larga scala.

PHP2Shell viene sfruttato con successo in attacchi reali, superando la fase delle scansioni e dei tentativi che aveva caratterizzato i primi giorni successivi alla divulgazione delle vulnerabilità critiche CVE-2026-109618 e CVE-2026-109619. La conferma arriva da Adel Karimi, responsabile delle attività di detection and response presso Perplexity, che ha documentato 35 esecuzioni di shell su tre honeypot configurati con Apache mod_php e PHP 8.4.26. L’indagine, pubblicata il 24 ottobre 2026 e ripresa il 26 ottobre, ricostruisce gli attacchi attraverso catture del traffico HTTP, registrazioni dei processi Linux e correlazioni temporali. Il risultato modifica il quadro operativo precedente: gli attaccanti non stanno più soltanto cercando sistemi vulnerabili, ma dispongono di una catena capace di ottenere effettivamente Remote Code Execution.

PHP2Shell conferma l’esecuzione di codice su tre server Apache

La ricerca originale di Adel Karimi e il rapporto tecnico sugli attacchi PHP2Shell ricostruiscono una campagna osservata il 24 ottobre 2026, nella quale due indirizzi IP hanno generato complessivamente 35 eventi di esecuzione di /bin/sh, direttamente collegati ai processi Apache in esecuzione sui sistemi bersaglio. I tre server erano honeypot appositamente predisposti per osservare attività ostili, identificati come T1, T2 e T3, equipaggiati con PHP 8.4.26, Apache mod_php e un limite di memoria PHP di 128 MiB. La ricerca distingue due episodi: il primo, originato dall’indirizzo 15.204.59.70, ha prodotto tre shell sul server T1; il secondo, proveniente da 162.35.99.94, ha generato 32 esecuzioni distribuite fra i tre sistemi, rispettivamente tre su T1, diciannove su T2 e dieci su T3. La prova non si limita alla presenza di errori HTTP o all’arresto dei processi PHP, fenomeni che in precedenza avevano prodotto numerose interpretazioni controverse. Ogni esecuzione confermata è associata a una richiesta HTTP completa, seguita da un evento process_exec registrato attraverso Tetragon, che identifica Apache come processo padre della shell avviata con UID 33, corrispondente all’utente del servizio web negli ambienti esaminati. I ricercatori hanno correlato porte sorgenti, timestamp, identificativi dei processi e sequenze delle richieste, escludendo di considerare un singolo indicatore come prova sufficiente. La distinzione è decisiva rispetto ai primi tentativi di sfruttamento PHP2Shell individuati prima della pubblicazione delle patch, quando numerosi scanner producevano errori o arresti dei servizi senza dimostrare l’esecuzione di codice arbitrario.

Leggi anche: PHP2Shell, allarme CSIRT Italia: l’81,9% dei servizi PHP risulta vulnerabile

Gli attaccanti aggirano ASLR attraverso una divulgazione della memoria PHP

La catena offensiva documentata da Karimi combina pressione sulla memoria, divulgazione di indirizzi e successiva esecuzione di comandi, utilizzando richieste HTTP multipart dirette ai server vulnerabili. La prima fase provoca una condizione di esaurimento della memoria durante l’inizializzazione della richiesta PHP, lasciando strutture interne in uno stato inconsistente. Una seconda richiesta sfrutta la gestione delle sessioni per ottenere una risposta contenente un cookie PHPSESSID anomalo, che nei casi documentati raggiungeva 819.200 byte di contenuto decodificato, equivalenti a 800 KiB. Questi dati non rappresentavano normali identificativi di sessione, ma comprendevano sequenze interpretabili come riferimenti a indirizzi di memoria. Gli attaccanti hanno quindi utilizzato le informazioni ottenute per adattare il payload alla disposizione effettiva della memoria del processo, superando le difficoltà introdotte da Address Space Layout Randomization (ASLR). La sequenza proseguiva attraverso un’ulteriore condizione di errore e una richiesta finale che conduceva all’avvio della shell. Il rapporto evidenzia che le prime tre componenti delle catene osservate presentavano contenuti identici fra bersagli differenti, mentre la richiesta di esecuzione cambiava in funzione degli indirizzi ricavati e del comando da lanciare. Questo comportamento è coerente con una tecnica che utilizza la divulgazione della memoria per adattarsi dinamicamente al bersaglio, anziché affidarsi a indirizzi predefiniti. La ricerca associa la catena osservata a CVE-2026-109618, ma precisa che le prove raccolte non consentono di dimostrare lo sfruttamento di un percorso autonomo riconducibile a CVE-2026-109619. Il risultato è dunque più preciso della generica affermazione secondo cui entrambe le vulnerabilità sarebbero state necessariamente sfruttate nella stessa operazione.

Trentacinque shell e tentativi di collegamento verso infrastrutture esterne

Le esecuzioni confermate non erano semplici dimostrazioni teoriche. Nel primo episodio osservato sul server T1, la sequenza offensiva si è conclusa alle 15:35:38 UTC, quando Tetragon ha registrato l’avvio di /bin/sh da parte del processo Apache, seguito dall’esecuzione del comando id. Il processo ha tentato di scrivere file di prova nella directory temporanea e nelle directory web, oltre a richiamare wget per effettuare una comunicazione esterna. Le scritture verso alcune directory sono state impedite dal filesystem in sola lettura e il tentativo di utilizzare wget non è riuscito perché il programma non era installato. Queste limitazioni non hanno però impedito l’esecuzione iniziale della shell, confermata dai registri del sistema. Nel secondo episodio, iniziato più tardi, gli attaccanti hanno variato i comandi utilizzando PHP CLI, curl e wget, cercando di raggiungere endpoint controllati dall’infrastruttura sorgente. Sono stati osservati tentativi di connessione TCP, esecuzioni di comandi per identificare utente, hostname e architettura del sistema e richieste costruite per includere queste informazioni nell’indirizzo contattato. La presenza di connessioni tentate non dimostra automaticamente il trasferimento riuscito di ulteriori payload o l’installazione di malware persistente, ma documenta la capacità degli operatori di impartire comandi al sistema compromesso. In diversi casi, dopo l’esecuzione della shell, il processo Apache terminava con un segmentation fault, lasciando tracce che potrebbero essere interpretate erroneamente come semplici anomalie applicative. La ricerca dimostra così che una richiesta HTTP può produrre esecuzione di codice anche quando il processo PHP successivamente si arresta, rendendo indispensabile correlare gli errori dei servizi con i processi effettivamente avviati.

La ricerca supera le incertezze sui precedenti tentativi PHP2Shell

La conferma di Karimi modifica un quadro che fino al 23 ottobre rimaneva caratterizzato da evidenze spesso incomplete. Amazon Threat Intelligence aveva identificato tentativi di sfruttamento già dal 17 ottobre, quattro giorni prima della distribuzione delle patch, ma non aveva potuto stabilire se le richieste avessero prodotto compromissioni riuscite. Analogamente, CrowdStrike aveva evidenziato le difficoltà necessarie per trasformare le vulnerabilità in exploit affidabili, soprattutto a causa delle differenze tra configurazioni PHP, versioni installate e modalità di gestione dei processi. Il rapporto originale di Amazon Threat Intelligence sulle attività osservate prima della divulgazione aveva inoltre segnalato l’utilizzo di infrastrutture di anonimizzazione e la presenza di differenti operatori offensivi, senza però attribuire con certezza gli attacchi a gruppi specifici. Le nuove evidenze hanno ricevuto una valutazione positiva anche da Marcus Hutchins, ricercatore di Expel, che ha riconosciuto nella ricostruzione una delle conferme tecnicamente più solide dello sfruttamento di PHP2Shell osservato su sistemi raggiunti da attaccanti esterni. Rimane però necessario distinguere le 35 esecuzioni su tre honeypot da una compromissione di 35 organizzazioni o server di produzione. Le due sorgenti IP individuate non dimostrano inoltre l’esistenza di due attori differenti: i payload condividono una struttura operativa e possono appartenere alla stessa famiglia di strumenti, senza fornire elementi sufficienti per stabilirne l’attribuzione. Non deve essere confusa con questo nuovo caso neppure la vicenda del presunto sfruttamento PHP2Shell contro un’organizzazione governativa europea, per la quale Unit 42 ha successivamente ritirato l’attribuzione iniziale alle due CVE. La novità del 26 ottobre consiste nella disponibilità di prove tecniche verificabili di esecuzione remota di codice, non nella conferma retroattiva di tutti gli incidenti precedentemente associati a PHP2Shell.

Continua con:

PHP2Shell, rilasciate le patch PHP contro due RCE senza autenticazione

PHP2Shell, 650 URL della PA a rischio: AWS rimuove le CA eMudhra

Patch immediate e controlli sui processi Apache per i server italiani

La documentazione delle prime catene di esecuzione riuscite rende ancora più urgente l’applicazione delle patch distribuite il 21 ottobre 2026 per le vulnerabilità CVE-2026-109618 e CVE-2026-109619. Le versioni corrette comprendono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35, mentre le installazioni appartenenti ai rami non più supportati richiedono un aggiornamento verso release mantenute oppure correzioni specifiche fornite dal distributore. Gli amministratori devono verificare che i nuovi binari siano realmente utilizzati dai processi web e procedere al riavvio dei worker interessati, evitando di considerare conclusa la mitigazione con la sola installazione dei pacchetti. Sul piano del rilevamento, la ricerca di Karimi suggerisce di esaminare richieste HTTP multipart anomale, risposte contenenti cookie PHPSESSID insolitamente estesi, errori di esaurimento della memoria e processi shell avviati direttamente da Apache. La presenza di un segmentation fault dopo una richiesta sospetta merita particolare attenzione, soprattutto quando coincide con l’avvio di strumenti come curl, wget o interpreti utilizzati per eseguire comandi. Gli indirizzi 15.204.59.70 e 162.35.99.94 costituiscono indicatori delle due sorgenti osservate, ma non devono essere interpretati come un elenco completo delle infrastrutture utilizzate dagli attaccanti. Resta inoltre aperta la questione della CVE-2026-115560, vulnerabilità distinta per la quale il PHP Security Team ha raccomandato di disabilitare session.upload_progress.enabled in attesa della correzione. Per le imprese, gli hosting provider e le amministrazioni pubbliche italiane, il passaggio decisivo è la trasformazione di PHP2Shell da rischio potenziale a tecnica di compromissione effettivamente osservata. Le rilevazioni nazionali del CSIRT Italia indicano centinaia di migliaia di servizi con versioni potenzialmente vulnerabili, ma non dimostrano che quelle installazioni siano state attaccate o compromesse. Il nuovo scenario impone quindi due attività parallele: completare tempestivamente gli aggiornamenti e verificare retrospettivamente i registri a partire almeno dal 17 ottobre, data dei primi tentativi individuati da Amazon. La disponibilità di una patch non chiude automaticamente l’incidente quando un attaccante potrebbe aver già eseguito codice sul sistema, e la differenza tra aggiornamento preventivo e risposta a una compromissione deve diventare il criterio principale per la gestione delle infrastrutture esposte.