PHP2Shell: perché gli attacchi sono esplosi in milioni di tentativi e perché non sempre funzionano

Nell'ultima settimana le vulnerabilità PHP2Shell hanno scatenato milioni di tentativi di sfruttamento, rilevati prima della divulgazione ufficiale da Cloudflare e Amazon. Le aziende hanno attivato protezioni WAF e monitorato i log, ma gli aggressori hanno continuato a testare varianti di exploit. Il dibattito tra la PHP Foundation e Chainguard sulla pubblicazione anticipata delle patch ha evidenziato le difficoltà nella gestione coordinata delle vulnerabilità. Gli esperti consigliano di adottare misure di difesa avanzate, monitorare le richieste sospette e applicare le patch tempestivamente.

Nel giro di poche ore, i tentativi di attacco tramite gli Exploit PHP2Shell sono cresciuti fino a raggiungere milioni di casi. Cloudflare ha rilevato traffico sospetto ancor prima che i bug venissero ufficialmente divulgati e Amazon ha scoperto tracce di sfruttamento quattro giorni prima del rilascio delle patch. La portata della minaccia si è rivelata maggiore rispetto alle stime iniziali.

Il CEO di Cloudflare, Matthew Prince, ha rivelato la dinamica degli attacchi all’infrastruttura dell’azienda. Dieci ore prima dell’annuncio pubblico dei problemi, i sistemi di difesa avevano registrato migliaia di tentativi di sfruttamento. Nei primi 45 minuti successivi alla divulgazione, il conteggio ha raggiunto decine di migliaia, due ore dopo ha superato le centinaia di migliaia e poche ore dopo ha toccato i milioni. Prince non ha specificato il numero finale di richieste né il numero di risorse attaccate.

Amazon Threat Intelligence ha fornito informazioni ancora più allarmanti. Gli specialisti dell’azienda hanno scoperto un tentativo di sfruttamento di PHP2Shell il 17 ottobre, quattro giorni prima della pubblicazione ufficiale delle vulnerabilità CVE-2026-109618 e CVE-2026-109619. La richiesta sospetta è entrata nel sistema honeypot MadPot e proveniva dall’indirizzo IP di una rete di anonimizzazione commerciale. I ricercatori non hanno ancora stabilito come il mittente sia venuto a conoscenza delle vulnerabilità prima della loro divulgazione.

La mattina del 21 ottobre, l’attività è aumentata significativamente. Tra le 2:00 e le 8:00 UTC, i sensori di Amazon hanno registrato nuovi tentativi di sfruttamento provenienti da diversi indirizzi associati all’infrastruttura di anonimizzazione. Gli aggressori hanno utilizzato diverse varianti di richieste malevole, portando gli analisti a sospettare il coinvolgimento di più gruppi indipendenti. Dopo il rilascio delle patch, nel giro di poche ore sono comparsi nuovi exploit dimostrativi, utilizzati quasi immediatamente contro gli honeypot di Amazon.

Le osservazioni di Cloudflare e Amazon confermano i tentativi diffusi di sfruttare PHP2Shell, ma non ci permettono di determinare il numero di intrusioni andate a buon fine. Amazon ammette esplicitamente che non è ancora noto se gli attacchi rilevati avrebbero funzionato su server reali. I dati di Cloudflare, inoltre, si riferiscono a richieste sospette, non a milioni di siti web compromessi. Non esistono ancora statistiche pubbliche affidabili sulle violazioni dei server.

Nel mezzo dei massicci attacchi, è scoppiato un conflitto tra gli sviluppatori PHP e Chainguard, un’azienda di sicurezza per componenti software. La PHP Foundation ha accusato Chainguard di aver violato la scadenza concordata per la divulgazione delle vulnerabilità. Secondo gli sviluppatori, l’azienda avrebbe pubblicato autonomamente immagini container PHP precompilate con patch il 21 ottobre alle 7:41 UTC, oltre sei ore prima del rilascio ufficiale.

Chainguard ha ricevuto le patch in anticipo, insieme ad altri fornitori di software, per preparare gli aggiornamenti per i clienti. Tuttavia, la pubblicazione prematura delle immagini compilate ha permesso di studiare le differenze tra le versioni di PHP vulnerabili e quelle corrette. Gli sviluppatori temevano che tale analisi avrebbe consentito di ricostruire il meccanismo di attacco prima che gli altri amministratori avessero ricevuto gli aggiornamenti. Al momento non ci sono prove che le azioni di Chainguard siano state la causa dei nuovi attacchi.

Il CEO di Chainguard, Dan Lorenz, ha difeso la decisione di rilasciare le patch in anticipo. Ha affermato che altri membri del gruppo di coordinamento avevano già osservato gli attacchi online e che le informazioni sulle vulnerabilità erano state diffuse pubblicamente. Lorenz sostiene di aver informato il gruppo di coordinamento della sua decisione e di aver reso disponibili le immagini con le patch a tutti, non solo ai clienti di Chainguard. Si è inoltre scusato con i manutentori di PHP per il disagio aggiuntivo causato.

Gli sviluppatori PHP non erano d’accordo con questa spiegazione. Nils Adermann, uno degli autori della dichiarazione della PHP Foundation, ha replicato a Lorenz affermando che i partecipanti alla discussione a porte chiuse avevano segnalato tentativi di intrusione e sfruttamento delle vulnerabilità del server, ma non avevano fornito alcuna prova di attacchi andati a buon fine. Adermann ha sostenuto che Chainguard aveva preso la decisione in modo indipendente, sebbene la tempistica della divulgazione fosse stata discussa congiuntamente in diverse occasioni. Pertanto, le parti non sono in disaccordo sulla tempistica della pubblicazione, bensì sulla valutazione della minaccia e sull’ammissibilità della violazione dell’embargo.

La pubblicazione concordata ha iniziato a vacillare il 20 ottobre. Intorno alle 15:00 UTC, sono apparsi sui social media due identificatori di vulnerabilità che valutavano erroneamente la vulnerabilità a 10 punti anziché ai reali 9,2. Gli sviluppatori hanno quindi posticipato la pubblicazione dal 22 al 21 ottobre. Successivamente, la società di ricerca Calif ha pubblicato per errore un video che dimostrava l’exploit, e copie della registrazione, poi cancellata, si sono rapidamente diffuse online. La PHP Foundation ritiene che il video abbia accelerato lo sviluppo di nuovi prototipi di attacco.

Cloudflare si era preparata in anticipo a questo scenario. L’azienda ha implementato regole di protezione il 21 ottobre alle 3:02 UTC sia per gli utenti gratuiti che per quelli a pagamento. Tuttavia, la semplice analisi delle richieste in entrata si è rivelata insufficiente. Gli specialisti hanno aggiunto la verifica delle risposte del server all’interno di una singola transazione HTTP per distinguere con maggiore precisione lo sfruttamento delle vulnerabilità dal traffico normale. Cloudflare ha osservato che gli aggressori modificavano le richieste malevole nel tentativo di aggirare i filtri.

Il nuovo meccanismo ha ampliato le capacità del WAF, un firewall per applicazioni web. Analizzando la richiesta e la risposta, il sistema è in grado di rilevare comportamenti sospetti e bloccare la trasmissione del risultato all’attaccante. Tuttavia, il blocco della risposta non garantisce che il server non abbia già elaborato la richiesta pericolosa. Pertanto, anche un filtraggio avanzato non elimina completamente gli errori PHP e non sostituisce l’applicazione di patch.

Le nuove statistiche modificano significativamente le stime sui tempi di risposta. Amazon raccomanda agli amministratori di monitorare i log dei server almeno a partire dal 17 ottobre, e non solo dopo la divulgazione ufficiale. Gli specialisti consigliano di prestare particolare attenzione alle richieste POST sospette, alle chiamate al meccanismo PHP_SESSION_UPLOAD_PROGRESS, all’esecuzione imprevista di comandi di sistema e alle modifiche dei file. Anche dopo l’installazione di una patch, un server potrebbe rimanere compromesso se un utente malintenzionato è riuscito a infiltrarsi nel sistema.

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