Articolo
Cybersecurity
Consulenza CISO-as-a-service: postura, roadmap di remediation, supporto continuativo.
Scopri →
CyberAgent
Vulnerability assessment continuo e gap analysis: scansione, mappatura sui requisiti dei framework, evidenze documentali pronte all’uso.
Scopri CyberAgent →
Il 21 ottobre PHP ha rilasciato le correzioni per CVE-2026-109618 e CVE-2026-109619, le vulnerabilità chiamate php2shell. Cinque giorni dopo le notizie sullo sfruttamento sono molte e non vanno tutte nella stessa direzione. Conviene separare quattro livelli: i tentativi di attacco, le esecuzioni di codice su honeypot, le compromissioni di sistemi reali e le notizie ritirate.
La ritrattazione di Unit 42
Il 23 ottobre alle 12:30 (ora del Pacifico) Unit 42 di Palo Alto Networks ha aggiunto al proprio threat brief i dettagli di un’intrusione contro un’agenzia governativa europea: attività successive alla compromissione che attribuiva a una piattaforma di AI agentica, con query di threat hunting. La notizia è stata ripresa ampiamente come il primo attacco a php2shell condotto con un agente AI.
Il 25 ottobre alle 14:15 Unit 42 ha ritirato quell’aggiornamento. La nota spiega che l’attività era stata osservata in un’applicazione PHP vulnerabile, ma che il team non riesce a confermare che l’accesso iniziale sia legato alle CVE di php2shell. La ritrattazione riguarda il collegamento con php2shell: Unit 42 non aggiunge altro sull’intrusione.
Diversi articoli e blog di fornitori continuano a presentare il caso come un attacco php2shell con un agente AI, e uno lo attribuisce a un gruppo statale. Sono ricostruzioni basate su un aggiornamento che la fonte stessa non sostiene più.
Cosa è stato osservato davvero
Tentativi. Sono documentati da prima del rilascio: Amazon li ha visti nei propri honeypot dal 17 ottobre, Cloudflare dal 21, come avevamo scritto nel primo pezzo.
Esecuzione di codice su honeypot. Secondo SecurityWeek, Adel Karimi, ricercatore di Perplexity, ha registrato il 24 ottobre 35 shell su tre honeypot con PHP 8.4.26, Apache mod_php e un solo worker. La catena ha quattro fasi: alcune richieste esauriscono la memoria, altre ne fanno trapelare il contenuto, l’ultima esegue un comando. Il traffico corrisponde a un proof of concept pubblico ed è coerente con CVE-2026-109618. Non è stato osservato il download di un payload di secondo stadio. Lo stesso Karimi avverte che la configurazione è volutamente favorevole e non misura l’affidabilità dell’exploit con altri worker, build o applicazioni. Marcus Hutchins (Expel) la definisce la conferma di sfruttamento reale di qualità più alta che abbia visto finora.
Compromissioni di sistemi reali. Nessuna fonte primaria ne ha confermate:
- ReliaQuest (aggiornamento del 22 ottobre) non ha osservato sfruttamenti riusciti negli ambienti dei clienti; ha ottenuto l’esecuzione di codice in laboratorio, dove i prerequisiti erano già presenti;
- CrowdStrike (23 ottobre) non ha osservato sfruttamenti riusciti né in rete né nei propri honeypot: molti proof of concept si limitano a far cadere il processo, e l’attaccante deve adattarli alla versione di PHP e all’applicazione del bersaglio. Un exploit universale è improbabile, uno per profili precisi come un’immagine Docker fissa è fattibile;
- CISA, secondo SecurityWeek, ha aggiornato il proprio alert il 23 ottobre con una regola di rilevamento Sigma dichiarando di non aver osservato sfruttamenti riusciti. Le due CVE non compaiono nel catalogo KEV, la cui ultima versione è del 23 ottobre.
L’esposizione
I numeri disponibili misurano installazioni esposte, non sistemi vulnerabili confermati, e i metodi sono diversi:
- Unit 42 (Cortex Xpanse): oltre 22,6 milioni di istanze esposte potenzialmente vulnerabili;
- Bitsight: fra le istanze con versione identificabile, circa un terzo usa un ramo coperto dal rilascio (8.2-8.5) e due terzi rami più vecchi; il ramo più diffuso è il 7.4, con oltre 2 milioni di osservazioni;
- Recorded Future, citando Modat, riporta circa il 79% dei servizi con versione leggibile su rami non più supportati; su VirusTotal circa 758.000 IP con rami a fine vita contro circa 272.000 con rami supportati.
Le cifre non sono confrontabili fra loro, ma indicano la stessa cosa: la maggior parte del PHP esposto che dichiara la versione gira su rami che non riceveranno una correzione ufficiale.
Cosa cambia per chi deve intervenire
- Il rischio realistico è la configurazione standard. Se un exploit funziona su un profilo preciso, i profili più diffusi (immagini Docker comuni, hosting con mod_php) sono i primi bersagli. Le installazioni standard vanno aggiornate per prime.
- I rami a fine vita vanno migrati. Per 8.1 e precedenti non c’è un rilascio: serve passare a un ramo supportato o verificare se il proprio fornitore offre un backport.
- Le mitigazioni restano parziali. CrowdStrike ricorda che disattivare l’upload progress delle sessioni non copre tutti i vettori; consiglia anche di disattivare gli upload dove non servono, limitare la dimensione delle richieste e dare a ogni applicazione un account separato con privilegi minimi.
- I log vanno controllati a ritroso, almeno dal 17 ottobre: processi del web server che avviano shell, file PHP nuovi nelle web root, connessioni in uscita anomale. Se c’è una compromissione, ReliaQuest raccomanda di ruotare credenziali, token e chiavi presenti sul server.
- I proof of concept non verificati non vanno eseguiti. Almeno un autore ha già invalidato la teoria su cui si basavano i propri, e il codice che circola può contenere malware.
Cosa ne pensiamo
In un caso che evolve di ora in ora, la qualità della fonte conta quanto la velocità. Un aggiornamento ritirato dopo due giorni ha avuto molta più diffusione della sua ritrattazione, e chi lo ha ripreso senza ricontrollare oggi racconta una storia che la fonte non sostiene più. Per chi deve decidere cambia poco: la priorità di php2shell non dipende dal fatto che a sfruttarlo sia un agente AI o una persona. Il dato che pesa davvero è un altro: la maggior parte delle installazioni che dichiarano la versione è su rami senza correzione. Il lavoro da fare resta sapere dove gira PHP, aggiornare o migrare e cercare tracce nei log, senza aspettare l’inserimento nel catalogo KEV.
Cosa monitorare
- Conferme di compromissioni da attività di incident response su sistemi reali, distinte dai risultati degli honeypot.
- L’inserimento delle due CVE nel catalogo KEV della CISA.
- Payload di secondo stadio ed exploit adattati ad applicazioni diffuse.
- Backport per i rami fuori supporto da parte di distribuzioni e fornitori.
Fonti
- Unit 42, Threat Brief: Critical Vulnerabilities in PHP: CVE-2026-109618, CVE-2026-109619
- SecurityWeek, PHP2Shell exploitation moves from probes to working shells
- CrowdStrike, PHP2Shell: obstacles to weaponizing likely constrain immediate exploitation
- ReliaQuest, PHP2Shell: responding to critical PHP vulnerabilities
- CISA, Known Exploited Vulnerabilities Catalog
- Bitsight, CVE-2026-109618 and CVE-2026-109619 (PHP2Shell)
- Recorded Future, PHP2Shell exploitation: two critical PHP flaws explained
- php2shell: due vulnerabilità critiche in PHP, cosa fare