Amazon: PHP2Shell sfruttato quattro giorni prima delle patch

Gli esperti di Amazon Threat Intelligence hanno rilevato che gli attaccanti hanno iniziato a sfruttare le vulnerabilità PHP2Shell (CVE-2026-109618 e CVE-2026-109619) quattro giorni prima della pubblicazione delle patch. I tentativi di sfruttamento sono stati registrati il 17 ottobre, con attacchi da reti commerciali di anonimizzazione.

Gli esperti di Amazon Threat Intelligence hanno riferito che gli attaccanti hanno iniziato ad sfruttare le vulnerabilità PHP2Shell già dal 17 ottobre 2026 — quattro giorni prima della pubblicazione delle patch e della divulgazione pubblica delle informazioni sui bug. Secondo i ricercatori, attualmente i tentativi di sfruttamento hanno assunto un carattere di massa.

Ricordiamo che sotto il nome generico PHP2Shell si celano due vulnerabilità critiche, recentemente corrette in PHP (CVE-2026-109618 e CVE-2026-109619) e valutate entrambe 9,2 punti sulla scala CVSS.

Entrambi i problemi sono legati alla gestione della memoria dopo il termine anomalo di una richiesta. In particolare, CVE-2026-109618 rappresenta una catena di problemi che porta alla corruzione della memoria a causa di out-of-memory, mentre CVE-2026-109619 è legata al mantenimento di uno stato globale obsoleto e consente di ottenere un use-after-free nell’heap. Di conseguenza, l’attaccante ottiene la possibilità di eseguire codice arbitrario con i privilegi del web worker o di leggere il contenuto della memoria del processo, dove possono trovarsi password, chiavi API, token e altri segreti.

La portata complessiva del problema è enorme. Infatti, le vulnerabilità PHP2Shell interessano praticamente tutte le versioni di PHP a partire da PHP 5.4, ovvero il problema riguarda PHP 5.4, 5.5 e 5.6, tutte le versioni di PHP 7.x, PHP 8.0 e 8.1, nonché PHP 8.2 fino a 8.2.35, PHP 8.3 fino a 8.3.36, PHP 8.4 fino a 8.4.27 e PHP 8.5 fino a 8.5.12. In pratica, i meccanismi vulnerabili erano presenti nel codice di PHP per più di 14 anni (la versione PHP 5.4 è stata rilasciata già nel marzo 2012).

Gli esperti di Amazon hanno riferito di aver rilevato nei log della loro rete di honeypot MadPot un tentativo di sfruttamento di PHP2Shell datato 17 ottobre 2026, mentre la divulgazione delle informazioni sui bug e il rilascio delle patch sono avvenuti il 21 ottobre.

Secondo i ricercatori, il tentativo di sfruttamento è stato effettuato da un indirizzo IP associato a una rete commerciale di anonimizzazione. Secondo le parole del direttore della sicurezza informatica di Amazon, CJ Moses, il tentativo assomigliava all’attività di un attaccante reale, anche se non è chiaro da dove potesse ottenere informazioni sulla vulnerabilità, che in quel momento era ancora sotto embargo. I rappresentanti di Amazon descrivono questa attività come un singolo tentativo.

Tuttavia, il 21 ottobre la situazione è cambiata e gli esperti hanno registrato l’uso di diversi PoC-exploit, nonché nuovi tentativi di attacco da un’altra infrastruttura anonimizzata. Inoltre, le differenze nei payload e nelle fonti del traffico indicavano la partecipazione di più gruppi di attaccanti.

In Amazon avvertono che non si può considerare il 21 ottobre come punto di partenza di una possibile compromissione: i log e la telemetria vanno verificati a partire dal 17 ottobre.

Dopo la divulgazione pubblica delle informazioni su PHP2Shell, il volume degli attacchi ha iniziato ad aumentare. Secondo i dati degli analisti di Cloudflare, già 10 ore prima della pubblicazione degli aggiornamenti ufficiali venivano registrate migliaia di tentativi di sfruttamento. 45 minuti dopo la pubblicazione delle patch, il conteggio è salito a decine di migliaia, due ore dopo a centinaia di migliaia, e successivamente il numero di tentativi di attacco è cresciuto fino a milioni.

Nel frattempo, gli attaccanti hanno iniziato ad adattare i payload alle protezioni. Gli esperti di Cloudflare hanno notato che gli attaccanti modificano le richieste, cercando di aggirare le regole WAF, e, a quanto pare, monitorano il volume dei trigger e cercano di adattare gli attacchi alla logica di funzionamento dei filtri.

Tuttavia, gli esperti di watchTowr osservano che molti PoC-exploit pubblicati in rete non funzionano affatto e verificano solo la differenza nei tempi di esecuzione o semplicemente causano il termine anomalo del sistema target.

Questo è confermato anche dai ricercatori di JFrog, che scrivono che GitHub è stato invaso da PoC-exploit sospetti. Gli esperti hanno scoperto sia exploit falsi che malware apertamente scherzosi. Ad esempio, uno di questi “exploit” cambia semplicemente lo sfondo del desktop della vittima in contenuti NSFW.

Nel frattempo, gli analisti di CrowdStrike osservano che rilevare un attacco reale può essere difficile. Poiché lo sfruttamento può avvenire prima dell’avvio del codice dell’applicazione web, il worker continuerà a funzionare, il server risponderà con HTTP 200 e nei log non apparirà nulla di sospetto. L’unico indicatore dello sfruttamento del bug potrebbe essere un errore di superamento del limite di memoria nel registro del server web, a cui è facile non prestare attenzione.

Luigi Zullo

Ricercatore di sicurezza informatica con esperienza nell’analisi delle vulnerabilità, nella mitigazione del rischio cyber, nelle attività di red teaming ed ethical hacking e nella protezione di sistemi complessi. Specializzato in penetration testing e Threat Intelligence, contribuisce al rafforzamento della resilienza digitale di infrastrutture e reti aziendali.

Aree di competenza: Penetration Testing, Threat Intelligence, Red Teaming, Vulnerability Assessment, Incident Response