PHP2Shell, gli attacchi precedono la patch: cosa cambia per i difensori

Ott 28, 2026 Giancarlo Calzetta Approfondimenti, Attacchi, Attacchi, In evidenza, News, RSS, Vulnerabilità 0

Il caso analizzato da Sekoia mostra perché aggiornare i sistemi deve accompagnarsi alla ricerca di compromissioni precedenti. Tra dipendenze nascoste e ricerca delle vulnerabilità accelerata dall’AI, i team di sicurezza devono prepararsi a intervenire anche prima che esista una correzione.

Il rilascio burrascoso delle informazioni sulle vulnerabilità PHP2Shell ha concentrato l’attenzione di tutti sulla delicatezza della fase che precede un annuncio importante, ma non bisogna trascurare le buone pratiche anche dopo che la patch è stata rilasciata. Un’analisi di David Greenwood per Sekoia mostra che il primo tentativo di sfruttamento di PHP2Shell rilevato da Amazon risale al 17 ottobre, quattro giorni prima del rilascio delle patch e questo ci ricorda che la verifica delle attività sospette deve coprire anche il periodo precedente.

Ricordiamo che PHP2Shell comprende due vulnerabilità del motore PHP, CVE-2026-109618 e CVE-2026-109619, che possono consentire l’esecuzione di codice da remoto senza autenticazione. La prima riguarda la gestione dell’esaurimento della memoria, la seconda uno stato interno che può sopravvivere alla liberazione della memoria cui fa riferimento. In determinate configurazioni l’attacco può avvenire prima dell’esecuzione del codice applicativo. Le correzioni sono state pubblicate il 21 ottobre nelle versioni PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35.

Gli attacchi rilevati hanno colpito degli honeypot

Nel suo report, Amazon ha documentato tentativi contro i propri honeypot precisando che non era chiaro se quei payload avrebbero avuto successo su sistemi reali, ma non è questo il punto. Secondo Sekoia, lo sfruttamento prima della divulgazione è destinato a diventare sempre più frequente per il software esposto su Internet. Apparati perimetrali, piattaforme di trasferimento file e runtime web offrono agli attaccanti un incentivo evidente: una sola falla può aprire l’accesso a un numero elevato di installazioni. La disponibilità della patch, quindi, non può più essere considerata il punto di partenza dell’esposizione al rischio.

Un secondo problema riguarda le dipendenze. La prossima emergenza, che in realtà sarebbe la riproposizione di qualcosa di già visto in passato, potrebbe nascere in una libreria incorporata in prodotti che l’organizzazione non sa nemmeno di usare indirettamente. Sapere quali applicazioni sono installate diventa insufficiente se manca il collegamento con i componenti che includono. Inoltre, aggiornamenti distribuiti senza un avviso di sicurezza possono rendere meno immediata l’identificazione del rischio attraverso gli scanner.

L’intelligenza artificiale può amplificare questa dinamica.

Nell’interpretazione di Sekoia, la pubblicazione di una classe di vulnerabilità offre ai ricercatori e agli attaccanti un modello da cercare in altro codice. Una scoperta importante potrebbe così generare una famiglia di problemi correlati, distribuiti fra prodotti e runtime differenti. Anche il vantaggio oggi disponibile ai team con accesso ai modelli più avanzati potrebbe ridursi con il miglioramento dei modelli aperti. A questo si aggiunge la fragilità degli embarghi: una dimostrazione pubblicata in anticipo o una correzione distribuita prima del previsto possono anticipare la circolazione delle informazioni.

Cosa devono fare i difensori?

Per i difensori, la prima conseguenza pratica è affiancare alla correzione un’indagine retrospettiva. Nel caso di PHP2Shell, la ricerca deve partire almeno dal 17 ottobre, anziché limitarsi ai giorni successivi alla pubblicazione delle patch. Applicarla elimina la vulnerabilità, ma non rimuove eventuali accessi o meccanismi di persistenza già introdotti.

La seconda priorità è migliorare l’inventario, collegando applicazioni, runtime e librerie incorporate. Sul piano operativo, questo significa poter rispondere rapidamente a una domanda concreta: quali servizi dipendono dal componente appena segnalato, chi li gestisce e quali sono raggiungibili dall’esterno?

Sekoia, inollre, raccomanda di proteggere le interfacce di amministrazione con controlli di accesso e di rimuovere dalla rete pubblica i servizi che non devono essere raggiungibili. In pratica, sottolinea l’importanza di regole che dovrebbero essere già la norma nella maggior parte delle aziende, ma spesso si perdono di vista.

Occorre poi decidere in anticipo come agire quando la patch non esiste. Disabilitare un modulo, applicare una regola al web application firewall o sospendere un servizio sono opzioni da valutare prima dell’emergenza, individuando anche chi può autorizzarle fuori dall’orario di lavoro. Per PHP2Shell, le mitigazioni di configurazione non sostituiscono l’aggiornamento completo.

Infine, la rilevazione deve seguire ciò che accade dopo lo sfruttamento: un processo web che avvia una shell, file inattesi nella directory del sito o connessioni in uscita insolite. Sono segnali da correlare e indagare, anche prima che la vulnerabilità riceva un nome. Per le falle già sfruttate sui sistemi esposti, anche i tempi di aggiornamento devono riflettere l’urgenza: la capacità di intervenire rapidamente deve andare insieme a quella di capire se qualcuno è già entrato.

Condividi l'articolo