PHP2Shell in Italia: il rischio per oltre 285mila servizi PHP

Ottobre è il mese europeo della cybersecurity, quello dei webinar sulla consapevolezza e dei poster in sala mensa. L’Italia lo chiude con il numero più imbarazzante dell’anno, certificato dal CSIRT nazionale nell’alert AL01/261025: su 741.523 servizi PHP rilevati nel Paese, 285.149 usano versioni potenzialmente vulnerabili a PHP2Shell. L’81,9%.

PHP2Shell in Italia: il dato corretto sull’81,9%

Prima di correre a ripubblicare la percentuale, fermiamoci sul denominatore, perché è qui che la maggior parte dei resoconti scivola. Quell’81,9% non è calcolato sui 741.523 servizi totali, ma sui 348.130 per i quali è stato possibile identificare la versione in uso: 285.149 diviso 348.130, non diviso il totale. Sul totale, i vulnerabili accertati sono il 38,5%.

Qualcuno potrebbe tirare un sospiro di sollievo: “ah, quindi è meno della metà”. Sbagliato, ed è il sospiro di sollievo più pericoloso del mese. I restanti 393.393 servizi non sono sicuri: sono ignoti. Non espongono la versione, il che significa che nessuno — nemmeno chi li gestisce, in molti casi — sa dire se siano patchati. Chi fa questo mestiere sa che un sistema di cui non conosci lo stato è un sistema di cui devi assumere il peggio.

La formula onesta, quindi, è questa: più di otto servizi PHP su dieci, tra quelli di cui si conosce la versione, risultavano vulnerabili al 25 ottobre. E la fonte del dato di esposizione è Censys, cioè scansione passiva di ciò che è visibile da Internet: lo stesso identico censimento che un attaccante può fare, gratis, in un pomeriggio.

PHP2Shell: vulnerabilità e versioni PHP da aggiornare

PHP2Shell è il nome collettivo di due vulnerabilità di remote code execution nell’interprete PHP, entrambe con CVSS v4.0 di 9,2 assegnato dal team di sicurezza PHP (il 10,0 circolato prima del rilascio è stato smentito dalla PHP Foundation). CVE-2026-109618 è una corruzione di memoria innescata in condizioni di out-of-memory, legata alla gestione impropria di longjmp(); CVE-2026-109619 è una RCE da “stale global state”, che Rapid7 classifica come use-after-free.

Il vettore, descritto anche dal CSIRT Toscana, è brutale nella sua semplicità: richieste HTTP multipart appositamente costruite, da remoto, senza autenticazione. Secondo CISA colpiscono tutte le installazioni PHP che servono richieste web, con il rischio massimo su Apache con mod_php, dove l’attacco può scattare prima ancora che venga eseguita una sola riga del codice applicativo. Tradotto: non importa quanto sia scritto bene il vostro gestionale — la falla sta sotto, nell’interprete.

Le patch disponibili dal 21 ottobre

Le patch esistono dal 21 ottobre, e la tabella è corta da leggere e lunga da applicare:

Per chi è fermo a PHP 8.1 o prima, il CSIRT è lapidario: il vendor non rilascerà patch né workaround. Tenable segnala backport minimali per i rami 7.4–8.1 e nulla per 5.4–7.3 — e chiunque abbia mai messo mano a un parco server italiano sa quanti CMS dimenticati girano ancora lì sopra.

Un esempio che dovrebbe far riflettere sul concetto di “PHP nascosto nei prodotti”: PAN-OS 12.1 e 12.2, cioè firewall Palo Alto, incorporano PHP 8.0.30. Il vostro inventario di PHP non coincide con la lista dei vostri siti web. Le note di rilascio della 8.2.35 chiudono ogni discussione sulle mezze misure: non esistono mitigazioni complete, aggiornare è l’unica scelta sicura.

Fragnesia: come si arriva ai privilegi di root

Il 28 ottobre CISA ha aggiunto al catalogo KEV una terza vulnerabilità, con una nota che è il vero titolo di questa storia: può essere concatenata con le due CVE di PHP “per installare webshell PHP ed eseguire comandi come root”. Si chiama Fragnesia, è la CVE-2026-46300, e qui serve subito un chiarimento che metà della stampa ha mancato: non è una falla PHP e non ha CVSS 9,2.

È una local privilege escalation nel kernel Linux — sottosistema XFRM, gestione ESP-in-TCP — con CVSS 3.1 di 7,8. Red Hat la classifica “Important” e non “Critical” proprio perché richiede accesso locale. Il punto è che PHP2Shell quell’accesso locale lo regala.

La parte tecnicamente elegante, e il motivo del nome: durante la coalescenza dei buffer di rete (skb), il kernel “dimentica” che un frammento è condiviso. La decifratura ESP in-place finisce così per scrivere dove non dovrebbe — sulla page cache di file di sola lettura. La proof of concept pubblica corrompe la copia in cache di /usr/bin/su e ottiene root.

Non serve modificare il file su disco: basta avvelenare la sua immagine in memoria, che è quella che il sistema esegue. Un dettaglio che vale una pillola operativa: sui sistemi già compromessi, avverte CloudLinux, la sola patch non basta, perché la page cache avvelenata e gli eventuali impianti sopravvivono alla correzione della falla.

E qui l’ironia amara: Fragnesia non è nuova. È stata divulgata il 13 maggio 2026 da William Bowling, con tanto di PoC pubblica, e secondo il ricercatore Hyunwoo Kim è stata attivata accidentalmente proprio dalla patch per Dirty Frag, la falla della stessa famiglia. Cinque mesi di preavviso. A maggio Tenable annotava che non era nel catalogo KEV; oggi c’è, con scadenza di remediation per le agenzie federali USA fissata al 31 ottobre. La falla ha aspettato pazientemente che qualcuno le costruisse intorno la catena giusta. L’attaccante non ha avuto fretta: ha avuto metodo.

Dall’accesso web al controllo dei firewall: la catena osservata

Fin qui la teoria delle CVE. Come si combinano nella pratica lo ha documentato la società israeliana Dream Security, su una campagna reale contro apparati di rete perimetrali — il tipo di ricostruzione che va presa come allerta qualificata e non come verità giudiziaria, perché l’attribuzione finale non è confermata in modo indipendente. Il percorso, però, è istruttivo e vale più di mille slide sulla “defense in depth”.

[embedded content: la catena di exploit · 4 stadi, da RCE web a root]

Quattro stadi. Primo, PHP2Shell con un exploit su misura — non pubblico, in quattro fasi — porta all’esecuzione di comandi come utente nobody, quello con cui gira il web server: privilegi minimi, la classica rete di contenimento. Secondo, qui entra Fragnesia: sovrascrive in page cache /etc/pam.d/su con pam_permit.so, e da quel momento il comando su concede root senza chiedere la password. Terzo, l’attaccante piazza una web shell PHP da 103 byte — centotré — e apre un tunnel SSH inverso. Quarto, pivot verso il server interno di gestione del firewall, raccolta di credenziali LDAP e tentativi su Active Directory.

I numeri della campagna raccontano il metodo: partendo da circa 19.000 firewall esposti individuati con il motore di ricerca FOFA, l’attaccante ha ristretto il bersaglio a 240 apparati tra Stati Uniti, Giappone, Taiwan e Corea del Sud, compromettendone 24, con i colpi concentrati tra il 23 e il 24 ottobre.

Il ricercatore Kfir Fleischer di Dream aggiunge il dettaglio che toglie ogni illusione di complessità: contro un apparato specifico, con gli offset precalcolati dal firmware, solo circa il 10% dei tentativi andava a segno, e la maggior parte dei fallimenti erano timeout. Non un bisturi infallibile, ma un martello che colpisce in fretta: la catena completa, quando funziona, si chiude in meno di quindici minuti. Il contenimento del “gira solo come nobody” è esattamente lo strato che Fragnesia cancella.

PHP2Shell e gli attacchi: quando la finestra si misura in ore

Se c’è un dato che riassume l’anno, lo ha messo in fila Ross McKerchar, CISO di Sophos, in un post intitolato senza mezzi termini “The breachpocalypse is here”. Citando il report AI Security 2026 della sua azienda: Ivanti Sentry (CVE-2026-10520) sfruttata entro 24 ore dalla pubblicazione di una proof of concept, LiteLLM (CVE-2026-42208) entro 36. La finestra tra divulgazione e sfruttamento non si misura più in settimane o giorni: si misura in ore.

Lo stesso post riporta una frase che pesa più di qualsiasi grafico: il 19 ottobre l’ex direttore cybersecurity della NSA, Rob Joyce, ha scritto che le società di incident response sono sature e stanno rifiutando lavoro. Quando chi dovrebbe spegnere gli incendi ha la coda fuori dalla porta, il calcolo del rischio cambia: non potete più contare sul “chiamiamo i pompieri quando succede”, perché i pompieri sono già impegnati altrove.

Sfruttamenti osservati e limiti dell’allarme

Detto questo, un articolo onesto deve anche raffreddare l’allarme dove i numeri lo raffreddano. Lo stesso McKerchar ammette che PHP2Shell, finora, non è diventato l’evento di sfruttamento di massa per cui in molti si erano preparati. GreyNoise ha rilevato almeno sei sfruttamenti riusciti delle due CVE PHP, non migliaia; Amazon aveva osservato tentativi già dal 17 ottobre, quattro giorni prima della divulgazione ufficiale, segno che qualcuno le conosceva in anticipo, ma la valanga annunciata non si è (ancora) materializzata.

Questo non è un motivo per rilassarsi: è il motivo per cui la finestra per agire è aperta adesso. La differenza tra chi patcha questa settimana e chi lo scopre tra un mese è esattamente la differenza tra sei sfruttamenti e il numero che leggeremo nel prossimo Rapporto Clusit. L’81,9% italiano è un invito a cena ancora apparecchiato: dipende solo da quanti decideranno di presentarsi come ospiti o come portata.

Come difendersi da PHP2Shell: patch e monitoraggio

Le raccomandazioni ufficiali convergono, ed è raro che ACN, CISA e NSA dicano la stessa cosa con questa compattezza. ACN e CSIRT: aggiornare subito, verificando che la patch sia davvero applicata anche quando i pacchetti arrivano dalle distribuzioni — perché “il repository dovrebbe averlo aggiornato” non è una verifica, è una speranza. WAF in modalità blocco solo se esistono regole specifiche per queste CVE, non le regole generiche di sei mesi fa.

E, formula che vale la pena rileggere due volte, in assenza di mitigazioni efficaci valutare di porre offline i servizi: lo mette per iscritto anche la NSA. Un servizio spento non viene bucato, e tra l’imbarazzo di un downtime pianificato e quello di un data breach la scelta economica è ovvia a chiunque sappia leggere un conto.

CISA aggiunge il punto che in Italia viene sistematicamente ignorato: fare inventario del PHP nascosto dentro altri prodotti, non solo dei siti web — il caso dei firewall Palo Alto con PHP 8.0.30 dovrebbe bastare come promemoria. E monitorare i processi: un worker PHP che lancia una shell o scarica strumenti è un segnale che nessun antivirus da solo intercetta, ma che un occhio sui log coglie subito. Dal 23 ottobre CISA fornisce anche una regola SIGMA pronta all’uso per chi ha un SIEM.

Ci sono due trappole operative da conoscere. La prima: alcune mitigazioni temporanee hanno effetti collaterali — disabilitare session.upload_progress, togliere il memory_limit — e vanno trattate come toppe provvisorie, non come soluzioni. La seconda: nel caso specifico di IceWarp esiste una terza CVE, la CVE-2026-115560, che richiede di disabilitare session.upload_progress anche dopo aver applicato la patch. Il messaggio di fondo, scritto dai manutentori PHP stessi nelle note di rilascio, resta quello: non esistono mitigazioni complete, aggiornare è l’unica scelta sicura.

Il mese della consapevolezza finisce oggi. La consapevolezza, quella vera, si misura dopodomani: non dal numero di webinar seguiti, ma da quanti di quei 285.149 servizi saranno ancora lì, con la stessa versione, quando ricominceremo a parlare d’altro. La domanda, allora, è una sola: il vostro PHP, quello che non sapevate nemmeno di avere, in quale metà della statistica vive?

Fonti

• ACN/CSIRT — PHP2Shell: aggiornare immediatamente i sistemi vulnerabili (AL01/261025)
• Matrice Digitale — PHP2Shell, il CSIRT sui servizi PHP vulnerabili in Italia
• CISA — Two Known Exploited Vulnerabilities added to Catalog (26/10/2026)
• BleepingComputer — CISA warns of Fragnesia Linux flaw chained in PHP2Shell attacks
• Tenable — Fragnesia (CVE-2026-46300) FAQ
• Rapid7 — CVE-2026-109618 e CVE-2026-109619: RCE critiche in PHP
• Sophos — The breachpocalypse is here (Ross McKerchar)
• The Register — Suspected Chinese attackers rooted 25 servers with custom PHP2Shell exploit
• PHP — Note di rilascio 8.2.35