PHPGeddon
Indice navigabile
Due vulnerabilità critiche, un embargo saltato, patch pubblicate in anticipo e attacchi iniziati prima della disclosure. La storia di PHP2Shell ci racconta qualcosa di molto interessante, e poco rassicurante, su come gestiamo la sicurezza informatica.
C’è una cosa che mi affascina della sicurezza informatica.
Passiamo anni a definire procedure, processi, responsabilità, standard e metodologie. Organizziamo riunioni, prepariamo calendari e stabiliamo esattamente chi deve fare cosa e quando.
Poi arriva la realtà.
E della nostra bellissima procedura se ne frega.
È quello che è successo nell’ottobre 2026 con PHP2Shell, ribattezzato anche PHPGeddon, il caso che ha coinvolto due vulnerabilità critiche nel cuore di PHP: CVE-2026-109618 e CVE-2026-109619.
Parliamo di problemi che, in determinate condizioni, consentono l’esecuzione remota di codice senza autenticazione.
Non proprio il massimo per una tecnologia sulla quale gira una parte enorme del web.
Ma oggi non voglio raccontarvi soltanto due vulnerabilità.
Voglio parlare di come è stata gestita la loro divulgazione, di un embargo che è andato progressivamente in pezzi e di attaccanti che, evidentemente, non avevano intenzione di aspettare il comunicato ufficiale.
Un problema che arrivava da lontano
Partiamo da un particolare piuttosto imbarazzante.
Già nel 2024, durante le attività successive a un audit di sicurezza condotto da Quarkslab, erano emersi i primi segnali del problema di gestione della memoria alla base di CVE-2026-109618.
Non era ancora stato dimostrato un percorso concreto di esecuzione remota di codice, ma il difetto era conosciuto.
E allora perché non era stato corretto?
Perché correggere il cuore di un linguaggio di programmazione utilizzato da milioni di applicazioni non è esattamente come aggiornare un plugin di WordPress.
Le possibili soluzioni introducevano problemi di compatibilità, rischi di denial of service oppure modifiche difficilmente coordinabili con l’enorme ecosistema delle estensioni.
Il team di sicurezza non riusciva a convergere su una soluzione.
E il problema rimaneva lì.
La stessa PHP Foundation ha riconosciuto che il ritardo è stato un fallimento strutturale, dovuto a difficoltà decisionali e alla scarsità di risorse specializzate.
Questo passaggio, secondo me, è fondamentale.
Perché possiamo avere sviluppatori estremamente competenti, ricercatori bravissimi e un progetto open source straordinario.
Ma se mancano le risorse e un processo decisionale efficace, anche un problema conosciuto può rimanere irrisolto per anni.
E PHP non è certo l’unico progetto open source in questa situazione.
Poi arriva l’intelligenza artificiale
Nell’estate del 2026, nuove attività di ricerca consentono di individuare percorsi di sfruttamento molto più gravi.
Calif, OpenAI e Wiz contribuiscono a chiarire il reale impatto di problemi precedentemente conosciuti.
L’intelligenza artificiale entra concretamente nel processo di ricerca, analisi e validazione delle vulnerabilità.
Attenzione, perché qui c’è una distinzione importante.
L’AI non ha inventato il difetto.
Ha contribuito a rendere più efficiente un’attività di ricerca che richiedeva conoscenze estremamente specialistiche.
Ed è proprio questo che dovrebbe preoccuparci.
Perché se un modello può aiutare un ricercatore a individuare una vulnerabilità, può potenzialmente aiutare qualcun altro a comprenderla e sfruttarla.
Non significa che gli attacchi siano tutti coordinati dall’AI.
Significa che i tempi con cui vengono individuate e analizzate le vulnerabilità possono cambiare radicalmente.
E le nostre procedure sono pronte a gestire questa accelerazione?
Il 20 ottobre comincia il circo
La divulgazione coordinata delle vulnerabilità era inizialmente prevista per il 22 ottobre 2026, alle 14:00 UTC.
Il principio era assolutamente sensato.
Informare i soggetti coinvolti, preparare le patch, consentire ai distributori di confezionare gli aggiornamenti e pubblicare tutto contemporaneamente.
Si chiama coordinated vulnerability disclosure.
L’obiettivo è evitare che le informazioni tecniche raggiungano gli attaccanti prima che i difensori abbiano una possibilità concreta di proteggersi.
Un meccanismo importante, soprattutto quando si gestiscono vulnerabilità così gravi.
Il 20 ottobre, però, gli identificativi CVE iniziano a circolare online.
Non erano ancora emersi tutti i dettagli tecnici, ma ormai era evidente che qualcosa di importante stesse per essere pubblicato.
La data del rilascio viene anticipata al 21 ottobre.
Poco dopo, viene pubblicato accidentalmente un video dimostrativo di un exploit.
Il video viene rimosso.
Peccato che qualcuno avesse già fatto in tempo a conservarne una copia.
E così, mentre il processo di disclosure tentava di mantenere il controllo, le informazioni iniziavano a diffondersi.
Un embargo che doveva proteggere la riservatezza stava progressivamente perdendo proprio quella caratteristica.
Il piccolo problema: gli attacchi erano già iniziati
Qui arriva la parte che trovo più interessante.
La rete di honeypot MadPot di Amazon aveva già intercettato un tentativo di sfruttamento di PHP2Shell il 17 ottobre.
Quattro giorni prima della disclosure pubblica.
E, soprattutto, tre giorni prima che gli identificativi CVE iniziassero a circolare online.
Il 21 ottobre vengono osservati ulteriori tentativi, provenienti anche da infrastrutture differenti.
Non sappiamo come gli attaccanti abbiano ottenuto le informazioni.
Potrebbero aver scoperto autonomamente il problema, aver ricevuto dettagli riservati oppure aver seguito altri percorsi che oggi non conosciamo.
E non abbiamo elementi sufficienti per affermare che questi primi tentativi abbiano prodotto compromissioni effettive.
Ma una cosa è chiara.
Gli attaccanti stavano già lavorando su PHP2Shell mentre molti difensori aspettavano ancora il rilascio ufficiale delle patch.
Capite il paradosso?
Abbiamo una procedura pensata per ridurre il vantaggio degli attaccanti.
Ma quando il segreto viene meno, rischiamo di trovarci con chi attacca già operativo e chi difende ancora vincolato al calendario.
Chainguard rompe l’embargo. Ed esplode la polemica.
Il 21 ottobre, alle 07:41 UTC, Chainguard pubblica immagini container che contengono le correzioni.
Più di sei ore prima dell’orario concordato.
La PHP Foundation critica duramente la decisione.
E ha delle ottime ragioni.
Chi dispone di una versione corretta può analizzare le differenze rispetto a quella vulnerabile e tentare di ricostruire il funzionamento dell’exploit.
Nel frattempo, molti altri utenti potrebbero non avere ancora accesso alle patch.
Questo crea una situazione potenzialmente pericolosa.
Chainguard, però, difende la propria scelta.
La decisione sarebbe stata presa anche alla luce delle informazioni sugli attacchi già osservati e della rapidità con cui era possibile individuare e sfruttare le vulnerabilità.
E qui viene il bello.
Perché, secondo me, entrambe le posizioni meritano di essere considerate.
Da una parte, rompere un embargo significa compromettere un processo di coordinamento sul quale hanno lavorato moltissime persone.
Dall’altra, continuare a rispettarlo quando ci sono evidenze credibili di sfruttamento attivo può diventare altrettanto problematico.
Non credo che la domanda più interessante sia stabilire chi avesse ragione.
La domanda è un’altra.
Perché il processo di disclosure non è riuscito a gestire efficacemente una situazione nella quale la riservatezza era ormai compromessa?
Perché le procedure di sicurezza devono prevedere anche le situazioni in cui qualcosa va storto.
Se funzionano soltanto quando tutti rispettano perfettamente le regole, forse non sono abbastanza robuste.
PHPGeddon e l’ondata di attacchi
Nei giorni successivi, la telemetria di sicurezza mostra un rapido aumento dei tentativi di sfruttamento.
Tra il 21 e il 25 ottobre, la rete CrowdSec registra 10.073 segnali riconducibili a PHP2Shell, provenienti da 1.187 indirizzi IP distinti.
Numeri importanti, che però vanno interpretati correttamente.
Non rappresentano 10.073 compromissioni.
E non dimostrano una campagna di sfruttamento riuscito su larga scala.
Molte richieste sembrano appartenere ad attività di scansione, test di exploit e ricerca opportunistica di sistemi vulnerabili.
Ho voluto confrontare questi dati anche con quelli raccolti attraverso CrowdSec su un’infrastruttura che monitoriamo.
Tra il 29 ottobre e il 5 novembre abbiamo registrato 12.131 alert, provenienti da 559 IP differenti.
Non tutti collegati a PHP2Shell, anzi.
Abbiamo osservato tentativi di accesso a file di configurazione, scansioni alla ricerca di vecchie vulnerabilità, richieste verso endpoint amministrativi e persino payload orientati all’esecuzione di comandi.
In alcuni casi, indirizzi appartenenti alla stessa sottorete hanno effettuato verifiche su percorsi differenti della medesima vulnerabilità a pochi secondi di distanza.
Un comportamento compatibile con sistemi automatizzati e attività distribuite.
Questi dati locali non dimostrano un collegamento diretto con PHP2Shell, ma mostrano molto bene il contesto nel quale si è verificata l’emergenza.
Internet è costantemente attraversata da strumenti che cercano vulnerabilità, credenziali dimenticate e servizi esposti.
E quando compare una nuova opportunità, una parte di questi sistemi può essere rapidamente riconfigurata per cercarla.
Non serve necessariamente un hacker incappucciato davanti a sei monitor.
A volte basta uno script, qualche server e una lista di indirizzi IP.
E se dietro ci fosse l’AI?
È una possibilità che non possiamo ignorare.
Oggi possiamo utilizzare modelli avanzati per analizzare codice, individuare comportamenti anomali, generare test e accelerare la ricerca di vulnerabilità.
È ragionevole ipotizzare che capacità analoghe possano essere sfruttate anche da attori offensivi.
Ma bisogna distinguere tra ciò che è tecnicamente possibile e ciò che possiamo dimostrare.
Una botnet distribuita non è automaticamente una botnet guidata dall’intelligenza artificiale.
Un attacco che cambia User-Agent non sta necessariamente imparando dalle risposte.
E un exploit comparso poche ore dopo una disclosure non dimostra da solo che sia stato scritto da un agente AI.
Quello che cambia, però, è il costo dell’automazione e della ricerca.
Più diventa semplice analizzare una vulnerabilità e sviluppare strumenti per sfruttarla, meno possiamo contare sul tempo che separa la pubblicazione della patch dall’arrivo dei primi attacchi.
Questo vale per chi difende.
Ma anche per chi attacca.
L’embargo non è il problema. La fiducia cieca nell’embargo sì.
Non voglio sostenere che la coordinated disclosure sia inutile.
Sarebbe una conclusione sbagliata.
Coordinare la pubblicazione delle vulnerabilità rimane fondamentale, soprattutto quando coinvolge progetti open source, distribuzioni, cloud provider e migliaia di applicazioni.
Ma il caso PHP2Shell evidenzia tre problemi che non possiamo ignorare.
Il primo è organizzativo: una vulnerabilità complessa può rimanere irrisolta troppo a lungo se mancano risorse e responsabilità decisionali chiare.
Il secondo riguarda la riservatezza: più soggetti sono coinvolti, più diventa difficile controllare completamente la circolazione delle informazioni.
Il terzo è operativo: quando emergono segnali di sfruttamento prima della disclosure, il processo deve poter reagire rapidamente senza trasformarsi in un ulteriore ostacolo alla difesa.
E c’è un quarto aspetto, forse quello più importante per chi amministra infrastrutture.
La data di pubblicazione di una CVE non è necessariamente la data dalla quale dobbiamo iniziare a cercare possibili compromissioni.
Per PHP2Shell, ad esempio, un’indagine retrospettiva dovrebbe considerare almeno il 17 ottobre.
Non il 21.
Quattro giorni di differenza possono essere moltissimi durante un incidente di sicurezza.
E quindi, cosa dovremmo imparare?
Che aggiornare rimane fondamentale.
Che conoscere realmente i propri asset esposti su Internet è indispensabile.
Che strumenti come WAF, IDS/IPS e sistemi di rilevamento comportamentale possono contribuire a ridurre il rischio, anche quando non esiste ancora una firma specifica per una vulnerabilità.
Che il virtual patching può essere una misura temporanea utile, ma non sostituisce la correzione del software vulnerabile.
E che conservare log sufficientemente dettagliati per effettuare indagini retrospettive non dovrebbe essere considerato un lusso.
Soprattutto, dovremmo smettere di considerare la sicurezza come una sequenza ordinata di eventi.
Scoperta della vulnerabilità.
Pubblicazione.
Aggiornamento.
Problema risolto.
Magari fosse sempre così.
Nella realtà, gli attacchi possono precedere la disclosure, le informazioni possono circolare prima del previsto e le patch possono arrivare in momenti differenti.
Il mondo reale non ha alcun obbligo di rispettare il nostro workflow.
Conclusioni
PHPGeddon non è soltanto la storia di due vulnerabilità critiche.
È la storia di un progetto open source che ha dovuto affrontare problemi tecnici estremamente complessi con risorse limitate.
È la storia di una disclosure coordinata che ha perso progressivamente il controllo delle informazioni.
È la storia di decisioni difficili, prese da soggetti diversi con responsabilità e priorità differenti.
Ed è anche un’anticipazione di quello che potrebbe diventare sempre più comune in un mondo nel quale l’intelligenza artificiale accelera la ricerca di vulnerabilità e la produzione di strumenti offensivi.
Possiamo discutere se Chainguard abbia fatto bene a rompere l’embargo.
Possiamo discutere se la PHP Foundation avrebbe dovuto anticipare ulteriormente il rilascio.
Possiamo discutere di procedure, responsabilità e processi decisionali.
Ma una cosa, secondo me, dovrebbe essere abbastanza evidente.
La nostra strategia di sicurezza non può dipendere dalla speranza che tutti rispettino il calendario.
Perché possiamo pianificare l’embargo, concordare la disclosure, preparare le patch e stabilire l’ora esatta della pubblicazione.
Ma c’è un piccolo dettaglio.
Gli attaccanti non hanno mai firmato il calendario.
Le opinioni in quanto tali sono opinabili e nulla ti vieta di approfondire l’argomento.
Risorse: