PHP2Shell: catena su 25 firewall e breccia in una rete governativa USA

Una settimana fa PHP2Shell era una storia di corsa alla patch: due bug critici in PHP, una release d'emergenza e la solita discussione su quanto in fretta si aggiornano tutte le macchine. Il 26 ottobre la società israeliana Dream l'ha trasformata in qualcosa di più netto: un'intrusione reale in cui un operatore sospettato China-nexus ha concatenato PHP2Shell con un exploit di privilege escalation del kernel Linux per rootare 25 server, in gran parte firewall esposti su Internet, e muoversi fino al dominio Active Directory di un'organizzazione affiliata al governo degli Stati Uniti. Nel toolkit dell'attaccante c'erano Claude Code e uno scanner cinese collegato ai modelli DeepSeek e Kimi. È la forma che i difensori temevano: una RCE pubblica, armata nel giro di giorni, guidata da un operatore che lavora alla velocità della macchina.

Notizia in evoluzione — pubblicata alle 17:34 (16:34 UTC) del 28 ottobre 2026. Aggiornata man mano che vendor e CISA pubblicano.

In breve

CVE	CVE-2026-109618 · CVE-2026-109619 (PHP2Shell) concatenati con CVE-2026-46300 (LPE kernel Linux, "Fragnesia")
Prodotto / versioni colpite	SAPI web di PHP · < 8.2.35 · < 8.3.36 · < 8.4.27 · < 8.5.12; i firewall violati usavano PHP 8.0.30 (fine vita). Vendor del firewall non divulgato
Corretta in	PHP 8.2.35 · 8.3.36 · 8.4.27 · 8.5.12 (rilasciate il 2026-10-21); backport sorgente per 7.4 · 8.0 · 8.1
CVSS	109618: 9.8 critica (NVD CVSS 3.1) · 9.2 critica (CNA PHP 4.0); 109619: 8.1 alta (NVD 3.1) · 9.2 (CNA PHP 4.0); 46300: 7.8 alta
Sfruttata attivamente	Sì · CISA KEV; Dream ha osservato una campagna che ha rootato 25 server il 2026-10-23/24
CISA KEV	Entrambe aggiunte il 2026-10-26; scadenza federale 2026-10-29 (BOD 26-04, triage forense richiesto). CVE-2026-46300 non elencata (catalogo 2026.10.27)
PoC pubblico	Sì · lo strumento "PHP2Shell" è pubblico; secondo Sansec i PoC pubblici richiedono condizioni aggiuntive su un'installazione di default
Advisory ufficiale	Release di sicurezza PHP · Rapporto di ricerca Dream

Cosa ha fatto PHP2Shell questa volta

Il resoconto di Dream si legge come un log operativo, perché lo è. La preparazione è iniziata l'8 ottobre; lo sfruttamento e il pivot sono andati avanti fino al 24. L'operatore ha estratto circa 19.000 firewall candidati dal servizio di scansione cinese FOFA, filtrati a circa 5.000 host attivi e poi a 240 bersagli, e ha lanciato lo sfruttamento batch automatizzato — cinque sessioni in parallelo, timeout di 1.800 secondi ciascuna. PHP2Shell è atterrato sul server appweb del firewall (PHP 8.0.30) attraverso il percorso session.upload_progress; ogni successo piantava una web shell PHP root da 103 byte e confermava il root con id. Ventiquattro firewall sono caduti tra Stati Uniti, Giappone, Taiwan e Corea del Sud; 22 sono stati lasciati "posseduti e parcheggiati" con web shell.

L'exploit del kernel è ciò che ha reso tutto più di una scorribanda di web shell. Dream riporta che l'operatore ha usato una falla di privilege escalation locale del kernel Linux, soprannominata "Fragnesia" (CVE-2026-46300, CVSS 7.8), per sovrascrivere /etc/pam.d/su con pam_permit.so — trasformando su in un passaggio a root senza domande. Da un firewall rootato l'operatore ha allestito un tunnel SSH inverso a otto porte con proxy SOCKS5, reso persistente tramite un servizio systemd e un hook rc.local, e l'ha usato per raggiungere il server di gestione interno dei firewall.

È quel server di gestione a far smettere il problema di essere "solo" un'appliance. La sua configurazione esponeva domain controller, un server SSO Keycloak, un'istanza GitLab, gateway VPN e un dominio Active Directory. Dream conferma che l'operatore ha decifrato una password di service account LDAP e ha enumerato ogni utente e gruppo; riporta — senza poterne confermare l'esito — un password spray contro un ambiente con lockoutThreshold=0, la creazione di utenti e account macchina backdoor sfruttando il MachineAccountQuota di default, e tentativi di estrarre le chiavi di firma SAML da un server Keycloak configurato con validate-idp-certificate: no.

Il risvolto AI è reale ma circoscritto, e Dream è prudente: Claude Code era installato, uno scanner chiamato aiscan era configurato con DeepSeek e Kimi, e la struttura e i commenti di circa 40 script "suggeriscono uno sviluppo assistito dall'AI". Ma Dream afferma chiaramente che non c'è "alcuna prova diretta" che i modelli abbiano scritto l'exploit o condotto l'attacco. La lettura China-nexus poggia su segnali circostanziali — bersagli in USA/Giappone/Taiwan/Corea del Sud, FOFA, lo strumento di tunneling iox, timestamp UTC+8 e prompt in lingua cinese nei log di aiscan — e Dream non nomina alcun threat actor. Tom's Guide ha riassunto la stessa cautela nel titolo: gli strumenti AI "potrebbero aver aiutato". Qui l'AI va trattata come un moltiplicatore di forza per un operatore umano, non come un attaccante autonomo.

Chi è esposto alla catena PHP2Shell

Il bug d'ingresso è in PHP, ma il danno atterra ovunque PHP giri su un percorso esposto — e le macchine violate erano firewall che impacchettavano un interprete a fine vita. PHP 8.0 è arrivato a fine vita a novembre 2023; 8.0.30 non ha una release binaria di progetto, solo un backport sorgente che i vendor di appliance devono raccogliere e distribuire. È qui il problema strutturale: le organizzazioni rootate quasi certamente non potevano risolvere con un apt upgrade, perché il PHP vulnerabile era dentro il firmware di un vendor.

Verificate cosa fate girare davvero:

• La versione di PHP, ovunque: php -v sugli host, ma anche dentro ogni CMS, pannello di controllo e appliance. session.upload_progress è attivo di default — php -i | grep -i upload_progress lo mostra.
• Appliance di frontiera: inventariate ogni dispositivo esposto con interfaccia web di amministrazione e chiedete al vendor quale branch di PHP impacchetta il firmware e se ha rilasciato la correzione.
• I bersagli del pivot: se un'appliance rootata poteva raggiungere un domain controller, Keycloak, GitLab o un piano di gestione, è quel percorso la breccia — non la web shell.

Remediation

CISA ha aggiunto entrambe le CVE PHP2Shell al catalogo KEV il 26 ottobre con scadenza federale al 29 ottobre e obbligo di triage forense ai sensi della BOD 26-04 — un orologio di tre giorni, perché la falla è usata per entrare in reti reali adesso. Il runbook passo-passo (comandi di patch per piattaforma, backport EOL, mitigazioni di configurazione) è nel nostro approfondimento sulla CVE PHP2Shell; lo script gratuito php2shell-check.sh dice in pochi secondi se un host è vulnerabile. Le azioni specifiche per questa campagna:

1. Applicate la patch — PHP 8.2.35, 8.3.36, 8.4.27 o 8.5.12. Per i branch a fine vita (7.4/8.0/8.1) applicate il backport sorgente o pretendete dal vendor dell'appliance un firmware corretto. Un interprete EOL su un firewall esposto è esattamente il modo di fallire documentato da Dream.
2. Non potete aggiornare l'appliance oggi? Un web application firewall davanti all'interfaccia di amministrazione fa guadagnare tempo, e togliere il piano di gestione da Internet elimina del tutto la superficie d'attacco. L'indicazione di CISA è netta: applicate la patch o spegnete.
3. Cacciate questa catena — non solo l'ingresso. Cercate un file PHP da 103 byte in una directory raggiungibile dal web; /etc/pam.d/su modificato per caricare pam_permit.so; unità systemd o voci rc.local inattese che avviano un tunnel SSH; traffico in uscita SOCKS5/SSH-inverso da un'appliance che non dovrebbe mai chiamare fuori (T1572, tunneling); processi worker PHP che lanciano shell (T1505.003, web shell; T1190, sfruttamento di app esposta). Lato AD: uso del service account LDAP dall'host di gestione del firewall, enumerazione massiva di utenti/gruppi, raffiche di password spray e nuovi account macchina (T1136, creazione account).
4. Bonificate e verificate dopo la patch. Ruotate la password del service account LDAP e tutto ciò che è raggiungibile da essa, revocate gli account AD creati dall'attaccante, estraete e sostituite le chiavi private di replica HA, TLS e autenticazione del dispositivo presenti su un firewall rootato, e ricostruite — una macchina con un pam.d sovrascritto e una web shell parcheggiata non è pulita, è reinstallata.

Cosa non si sa ancora

• Vendor del firewall e versioni di firmware colpite non sono divulgati. Dream ha avvisato il vendor; finché non c'è un advisory con nome, la correzione a livello di dispositivo è "chiedete al vostro vendor".
• Se la compromissione di AD sia riuscita. Dream conferma la decifratura della password LDAP e l'enumerazione del dominio, ma segna come tentati — esito ignoto — il password spray, la creazione di account backdoor e l'estrazione delle chiavi SAML.
• La mappatura della CVE del kernel. La LPE è riportata da Dream come "Fragnesia" / CVE-2026-46300; il record pubblico NVD per quell'ID descrive un bug di gestione dei frammenti nello stack di rete del kernel e non è in KEV. Verificate con il vostro vendor del kernel prima di affidarvi all'identificativo esatto.
• L'attribuzione. La lettura China-nexus è di Dream, tratta da indicatori circostanziali; nessun attore nominato e nessun coinvolgimento governativo confermato.

La lezione sta nel pivot, e lì sta anche la risposta difensiva. La web shell sul firewall era di fatto invisibile — è un'appliance che fa girare un interprete non strumentabile, e la prima prova reale per la vittima è stata un comportamento, non un log di endpoint: un tunnel che chiama fuori, un service account LDAP che si autentica da un dispositivo che non tocca mai AD, raffiche di enumerazione e spray che attraversano la rete. Il motore di analisi del traffico di Zero Hunt è costruito proprio per questo punto cieco — un modello deep-learning con quattro teste di inferenza (traffico sospetto, malware, tipo di attacco, fingerprint applicativo) addestrato su miliardi di sequenze PCAP, in esecuzione sulla GPU dell'appliance on-premise, che segnala il tunnel SOCKS5 e l'autenticazione anomala del service account mentre il pivot accade, non nel digest SIEM del mattino dopo. E poiché gli attaccanti oggi concatenano una RCE pubblica a una LPE del kernel fino alla breccia del dominio più in fretta di quanto reagisca un test trimestrale, la postura difensiva onesta è lanciare la stessa catena contro sé stessi per primi: Zero Hunt è un red team AI autonomo che identifica l'esatta appliance e build di PHP sul vostro perimetro, scrive un exploit per quel bersaglio e — con un umano che approva ogni passo che conta — dimostra se quel firewall raggiunge il vostro domain controller prima che lo faccia l'operatore di qualcun altro.