PHP2Shell: Amazon ha rilevato tentativi di exploit 4 giorni prima della patch di PHP (aggiornato: 22 ottobre 2026, ore 20:50)

Quattro giorni prima che le patch per PHP2Shell fossero rilasciate, un honeypot di Amazon registrava già un tentativo di sfruttamento. Lo riferisce Amazon Threat Intelligence, e il dettaglio cambia il modo in cui va affrontato l'incidente. Per qualche giorno, qualcuno potrebbe aver avuto in mano informazioni su una falla ancora sotto embargo, senza alcuna correzione disponibile. Per chi amministra applicazioni PHP, quindi, la data dell'advisory non segna l'inizio del rischio. Aggiornare è obbligatorio, ma non basta: bisogna anche guardare indietro.

Il 17 ottobre, nella trappola di AWS

Il tentativo è emerso dalla telemetria di MadPot, il sistema di honeypot interno con cui AWS monitora, studia e contrasta il crimine informatico. Gli analisti lo hanno individuato mercoledì, ripercorrendo a ritroso l'attività registrata dai sensori. La richiesta proveniva da un indirizzo IP associato a una rete commerciale di anonimizzazione, geolocalizzato in Australia.

«Mentre la vulnerabilità era ancora sotto embargo, il fatto che un honeypot sia stato preso di mira da un indirizzo IP anonimizzato suggerisce che dietro l'attività ci fosse un attaccante, anche se non è chiaro come abbia ottenuto informazioni sull'exploit prima della divulgazione», ha dichiarato CJ Moses, CISO di Amazon Integrated Security.

Un portavoce di Amazon ha poi ridimensionato l'episodio, definendolo «in gran parte un tentativo isolato». La finestra di quattro giorni poggia quindi su un singolo evento, di cui non si conosce l'esito.

» Leggi: Allarme rosso per PHP: due vulnerabilità critiche consentono l'hack immediato di qualsiasi sito (PHP2Shell)

Amazon ha osservato il primo exploit intorno alle 02:00 UTC del 21 ottobre, seguito fino alle 08:00 UTC da altri tentativi provenienti da infrastrutture anonimizzate diverse, con payload differenti.

È il segno, probabilmente, di più attori in azione. Anche Hadrian, Patchstack e Cloudflare hanno registrato attività nelle ore precedenti la correzione. «Nelle 10 ore prima dell'annuncio pubblico, sulla rete Cloudflare abbiamo visto migliaia di tentativi di sfruttamento. Nei 45 minuti successivi sono diventati decine di migliaia, centinaia di migliaia entro 2 ore, e ora sono milioni», ha dichiarato Matthew Prince, CEO di Cloudflare.

Cosa fare adesso: aggiornare, poi indagare dal 17 ottobre

La priorità è installare subito le versioni corrette.

» Leggi: Come aggiornare PHP su Linux (Ubuntu, Debian, RHEL, Rocky Linux, AlmaLinux e Fedora)

Amazon però insiste su un secondo passaggio. «Un embargo protegge i difensori solo finché qualcun altro non trova lo stesso bug», scrive l'azienda, e la raccomandazione è esplicita: per PHP2Shell le indagini vanno condotte almeno a partire dal 17 ottobre, non dalla data dell'advisory.

Il problema è che le tracce sono scarsissime. «I processi worker restano stabili, le risposte restituiscono HTTP 200 e i log dell'applicazione non registrano anomalie, perché nessuna riga di codice applicativo è mai stata eseguita. L'unica traccia lato server è un singolo errore fatale per superamento del limite di memoria nel log degli errori del web server, abitualmente liquidato come rumore», ha spiegato CrowdStrike. In pratica, conviene passare al setaccio il log degli errori del web server alla ricerca di errori fatali legati a memory_limit, soprattutto se compaiono in date sospette.

Sul piano strutturale, Amazon chiede di misurare in ore, non in giorni, i tempi di correzione delle vulnerabilità critiche sui sistemi esposti. «Uno SLA di 7 o 30 giorni presuppone un margine che non esiste più», avverte l'azienda, che consiglia anche sistemi di rilevamento non basati su firme specifiche per singoli CVE. Il motivo è semplice: con l'analisi assistita dall'AI, trasformare un diff o un advisory in un exploit funzionante costa sempre meno. Ogni nuova falla, quindi, potrebbe essere sfruttata nel giro di poche ore, o addirittura prima ancora di diventare pubblica.

Fonti: thehackernews.com, aws.amazon.com, wired.com