In questo articolo Indice dei contenuti 3 sezioni
La vicenda PHP2Shell rischia di diventare l’argomento più convincente degli ultimi anni per chi vende soluzioni di sicurezza applicativa. Due vulnerabilità di esecuzione remota di codice nel linguaggio che fa girare il 69% del web, scoperte con l’aiuto dell’intelligenza artificiale e sfruttate dagli attaccanti prima ancora che arrivasse la patch, sembrano spingere verso una conclusione ovvia: trovare più bug e correggerli più in fretta. Eppure il punto vero è un altro. I team di sicurezza non riescono a correggere alla velocità delle macchine, ma possono limitare ciò che un aggressore raggiunge dopo l’attacco, mettendo l’identità al centro del controllo. La gravità finale di un incidente dipende infatti soprattutto da quali account di servizio, chiavi API, ruoli cloud e token il sistema compromesso può usare, e da cosa questi permettono di toccare.
Lo sfruttamento corre più veloce delle correzioni
Le due falle dietro PHP2Shell erano nel codice di PHP dal 2012. I ricercatori di Calif e Wiz le hanno individuate ad agosto con il supporto dei modelli di OpenAI e Google, e le hanno rese pubbliche insieme a OpenAI. Amazon aveva già osservato un tentativo di sfruttamento il 17 ottobre, quattro giorni prima della divulgazione. PHP ha rilasciato la correzione il 21 ottobre e nello stesso giorno watchTowr ha rilevato attacchi reali. Cloudflare ha poi visto il traffico malevolo crescere rapidamente, finché il 26 ottobre la CISA ha inserito entrambe le vulnerabilità nel suo elenco di quelle attivamente sfruttate.
Sul fronte della remediation le cose vanno molto più piano. Secondo il DBIR 2026 di Verizon, il tempo mediano per sistemare una vulnerabilità nota e già sfruttata è di 43 giorni. Qualys indica un tempo medio di 21,2 giorni e segnala che il 63% delle falle critiche resta aperto dopo una settimana. Nel frattempo vengono pubblicate circa 195 nuove CVE al giorno. Per PHP2Shell la pulizia sarà ancora più lenta, perché PHP è integrato in appliance e pannelli di hosting che i clienti non possono aggiornare da soli, e le versioni 8.1 e precedenti non hanno ricevuto build ufficiali. Al 27 ottobre Censys contava 32,5 milioni di servizi PHP esposti su internet con versioni potenzialmente vulnerabili, più altri 60 milioni che non dichiarano affatto la versione.
Trovare un bug non significa risolverlo
Anche se una scansione basata sull’intelligenza artificiale scovasse domani 2.000 nuove zero day in un’infrastruttura aziendale, la protezione non migliorerebbe di colpo. Ne uscirebbe semplicemente un elenco, con alcune voci facili da sistemare e altre che richiedono più tempo di quello disponibile. Per i rami di PHP ancora supportati bastava installare la versione aggiornata, eppure governi e aziende hanno comunque spento i propri siti in attesa della patch.
C’è però un modo più ottimista di guardare la questione. In un contesto aziendale l’impatto di un attacco dipende da quanto lontano arrivano le identità compromesse. Una shell su un server PHP dà accesso a tutto ciò che quel server può leggere, dalle variabili d’ambiente alle chiavi cloud nei file di configurazione. PHP2Shell può anche far trapelare la memoria dei processi worker, con dentro password, token e chiavi API. Chi esegue codice su un host apre una porta su un corridoio, ma gli oggetti di valore stanno di solito in stanze chiuse a chiave. E i controlli che frenano il movimento laterale non dipendono dalla gara contro la scoperta delle falle, perché ridurre la portata di un account di servizio è un compito misurabile.
Gli attaccanti scelgono la strada più comoda
L’approccio ha dei limiti evidenti. Se la falla si trova nell’identity provider o nel gestore dei segreti, il movimento laterale è già servito. Se colpisce il database o lo storage, l’aggressore è già arrivato a destinazione. Partire dalle vulnerabilità, catalogarle e ordinarle per gravità significa puntare sul punteggio CVSS più che sul raggio d’impatto. Ma gli attaccanti non cercano il percorso più diretto, cercano quello più facile, e sfruttare una credenziale trapelata è molto più semplice che concatenare zero day per raggiungere un database.
Il caso LiteLLM di ottobre lo dimostra bene. Gli aggressori hanno usato una master key esposta in un repository pubblico per recuperare, da una piattaforma interna di agenti, un token GitHub da proprietario dell’organizzazione privo di limitazioni. Con quell’identità hanno rubato altri due token dei maintainer, manipolato il flusso di rilascio e pubblicato pacchetti progettati per sottrarre credenziali. La strada indicata è censire ogni agente AI e ogni identità non umana, partendo da quelle che arrivano più lontano, assegnare un responsabile, limitare gli accessi allo scopo reale, eliminare le credenziali inattive e governarne l’intero ciclo di vita. Per gli agenti si può spingersi oltre e concedere permessi in base all’intento, perché la patch decide quanto in fretta si chiude una falla mentre l’identità decide quanto ottiene un aggressore quando chiuderla in tempo non è possibile.
Fonte: TecnoAndroid