PHP2Shell, trovata in una settimana e corretta in settantuno giorni
Il 21 ottobre il ministero dell'Interno ha oscurato le pagine delle prefetture. Non c'era stato un attacco: si aspettava di installare una correzione. Lo stesso giorno hanno spento per precauzione alcuni siti pubblici anche il fornitore informatico del governo federale tedesco e il ministero degli Esteri belga.1
La causa sono due falle in PHP, il linguaggio con cui funzionano WordPress, Drupal e il 69,3% dei siti di cui si conosce la tecnologia lato server.2 Le hanno chiamate PHP2Shell: permettono a chiunque, senza password, di far eseguire comandi al server. L'Agenzia per la Cybersicurezza Nazionale le ha classificate critiche, con un punteggio di 9,2 su 10.3
Sono state trovate con l'AI. Il 1° agosto Ryan Austin, ricercatore di Calif, invitato da OpenAI nel progetto Patch the Planet, ha individuato la prima rileggendo il codice insieme a un modello linguistico, e l'11 agosto l'ha segnalata agli sviluppatori di PHP. Austin precisa che nessun modello trova «tutti i bug» con richieste semplici: ha contato la sua conoscenza delle vecchie falle di PHP.4 Il 19 agosto, per conto suo, ci è arrivato anche un ricercatore di Wiz, con Gemini 4 Argon e GPT-5.6 Sol. Secondo Wiz, a una sola persona è bastata una settimana.5
Le correzioni sono uscite il 21 ottobre, settantuno giorni dopo la prima segnalazione. La PHP Foundation racconta che i primi segni di uno dei due problemi erano emersi già nel 2024, durante una revisione del codice, e che la correzione era rimasta bloccata per mesi tra soluzioni diverse. Il lavoro sulla sicurezza di PHP, scrive, poggia su un piccolo gruppo di sviluppatori pagati dalla fondazione e su un po' di aiuto volontario.6
Gli attacchi non hanno aspettato. Amazon ha registrato il primo tentativo il 17 ottobre, quattro giorni prima della correzione.7 Il 20 ottobre l'embargo si è rotto e i dettagli sono circolati in rete. Secondo quanto ha scritto su X l'amministratore delegato di Cloudflare, Matthew Prince, i tentativi sono passati da qualche migliaio nelle dieci ore prima dell'annuncio a decine di migliaia nei 45 minuti successivi, e poi a milioni.8 Il 23 ottobre l'ACN ha aggiunto una terza falla collegata, che riguarda anche le versioni già aggiornate.3
PHP2Shell, il tempo per trovarla e quello per correggerla
E c'è chi la correzione non la riceverà. Gli aggiornamenti riguardano le versioni dalla 8.2 alla 8.5; per la 8.1 e le precedenti, che non sono più supportate, il CSIRT Italia avverte che non arriveranno patch ufficiali.3 Secondo W3Techs, più di un sito PHP su tre gira ancora sulla versione 7 o sulla 5.2
Siti in PHP, per versione
PHP2Shell è il caso più visibile di quello che succede da qualche mese: con l'AI una falla si trova in pochi giorni, per correggerla servono mesi, e chi attacca arriva prima della correzione. I numeri degli ultimi mesi dicono che non è un caso isolato.
Seimila falle segnalate, cinquecento corrette
Il 7 aprile Anthropic ha lanciato Project Glasswing. Un gruppo di aziende che gestiscono software critico, tra cui Amazon, Apple, Google, Microsoft e la Linux Foundation, ha avuto accesso a Claude Mythos Preview, un modello non in vendita, per cercare falle nei propri sistemi prima che le trovasse qualcun altro. Anthropic ha messo a disposizione fino a 100 milioni di dollari in crediti per usare il modello e 4 milioni di donazioni alle organizzazioni che curano la sicurezza del software open source.9
Il 6 ottobre è arrivato un nuovo bilancio. Tra aprile e luglio i partner hanno trovato almeno 129.000 vulnerabilità verificate, e più di 33.000 sono state classificate come critiche o gravi. Anthropic precisa che il conto è parziale, perché si basa sui rapporti di 33 partner. Sulle correzioni, invece, non c'è un totale: meno della metà dei partner ha comunicato quante falle ha sistemato, spesso perché il lavoro era ancora in corso.10
Per il software open source, scritto e mantenuto in pubblico, spesso da volontari, Anthropic tiene un registro. Al 2 ottobre il modello aveva proposto 29.439 possibili falle. Quelle segnalate ai manutentori, cioè a chi cura ciascun progetto, erano 6.157, in 591 progetti. Quelle corrette, per quanto ne sa l'azienda, erano 516: poco più di una su dodici.11 Il registro avverte che il dato arriva in ritardo, anche perché alcuni manutentori correggono senza annunciarlo, e che una correzione pubblicata non è ancora una correzione installata.
Già il 22 maggio l'azienda aveva scritto che il limite non era più trovare i bug, ma la capacità umana di smistarli, segnalarli, preparare le correzioni e distribuirle. Diversi manutentori avevano detto di essere «gravemente a corto di capacità», e alcuni avevano chiesto di rallentare le segnalazioni per avere il tempo di scrivere le patch.12
La finestra si è chiusa
Il problema sarebbe più piccolo se ci fosse tempo. Mandiant, la società di risposta agli incidenti che fa parte di Google, misura da anni il «tempo per lo sfruttamento»: quanti giorni passano, in media, tra l'uscita di una correzione e il primo attacco che usa quella falla. Nel 2018-2019 erano 63, nel 2023 cinque.13 Nel rapporto M-Trends pubblicato il 23 marzo 2026, sui casi del 2025, la stima è di meno sette: l'attacco arriva in media una settimana prima della correzione.14
Quanto tempo resta prima dell'attacco
| Periodo | Tempo medio tra la correzione e il primo sfruttamento |
|---|---|
| 2018-2019 | 63 giorni dopo |
| 2020-inizio 2021 | 44 giorni dopo |
| 2021-2022 | 32 giorni dopo |
| 2023 | 5 giorni dopo (47 contando 15 casi anomali) |
| 2025 | 7 giorni prima, stima |
Il Fondo monetario internazionale ci è arrivato da un'altra strada. Nel rapporto sulla stabilità finanziaria di ottobre mette gli attacchi informatici tra i rischi in crescita per i mercati, e nel commento che lo accompagna scrive che, in oltre il 70% dei casi segnalati quest'anno, i produttori di software non hanno avuto quasi il tempo di correggere una falla prima che gli attaccanti la sfruttassero. Nel 2021 la quota era meno della metà, e di solito per la correzione c'erano quasi 300 giorni.15
I modelli che trovano le falle sono gli stessi che, in altre mani, aiutano a sfruttarle. Il 3 settembre OpenAI ha scritto che GPT-6 Astra è il suo primo modello a raggiungere il livello «Critical» di capacità informatica nel suo sistema di valutazione dei rischi: con gli strumenti e gli accessi giusti trova falle sconosciute e costruisce modi nuovi per sfruttarle su molti sistemi ben protetti, senza una persona che guidi ogni passo.16 Quanto costi a un criminale mettere in fila queste capacità l'ho raccontato nel pezzo sugli attacchi da 25 dollari ai negozi online.
Chi ripara resta indietro
Dall'altra parte c'è chi le correzioni deve installarle. Il Data Breach Investigations Report 2026 di Verizon, uscito il 20 maggio, ha seguito in più di 13.000 organizzazioni le falle del catalogo KEV, l'elenco delle vulnerabilità già sfruttate tenuto dall'agenzia americana per la cybersicurezza, la CISA. Nel 2025 solo il 26% era stato corretto del tutto, contro il 38% dell'anno prima. Il tempo mediano per chiuderle è salito da 32 a 43 giorni.17
Verizon non dà la colpa alla pigrizia. Nel 2025 le organizzazioni hanno corretto 63,7 milioni di casi prima ancora che la falla entrasse nel catalogo, il 30% in più dell'anno prima. Ma il volume è cresciuto più in fretta: nel campione di Verizon i rilevamenti di vulnerabilità sono passati da 68,7 milioni nel 2022 a 527,3 milioni nel 2025, quasi otto volte tanto. Gli autori parlano di «un tapis roulant che accelera». E sono dati del 2025, precedenti ai nuovi modelli di primavera.
Quando dietro un progetto c'è una squadra pagata, la catena regge. Mozilla, provando Mythos, ha trovato e corretto 271 vulnerabilità in Firefox 150, più di dieci volte quelle trovate in Firefox 148 con Claude Opus 4.6.12 Nei progetti open source il peso cade spesso su volontari. Alla fine di ottobre 2025 i manutentori di FFmpeg, la libreria che legge audio e video in moltissimi programmi, hanno ricevuto da Big Sleep, lo strumento di Google basato sull'AI, la segnalazione di una falla nel decodificatore di un vecchio formato LucasArts, usato nei primi fotogrammi di un videogioco del 1995. L'hanno corretta, e poi hanno chiesto in pubblico se sia giusto che aziende da migliaia di miliardi di dollari usino l'AI per cercare problemi di sicurezza nel codice che altri scrivono per passione. Con le regole di Google, la falla diventa pubblica dopo 90 giorni, corretta o no.18 Lo stesso squilibrio, nel kernel Linux e in curl, l'avevo descritto parlando di chi controlla il codice scritto dall'AI.
Eppure scrivere una correzione è una parte che l'AI sa già fare. Nella finale dell'AI Cyber Challenge della DARPA, nell'agosto 2025, i sistemi delle sette squadre hanno trovato 54 delle 63 falle inserite apposta nel codice e ne hanno corrette 43, in media in 45 minuti e con una spesa media di circa 152 dollari per compito. Hanno trovato anche 18 falle vere che nessuno conosceva e hanno proposto 11 correzioni.19 La strozzatura sta dopo: qualcuno deve leggere la correzione, provarla, approvarla e installarla su ogni computer che usa quel software.
In Italia, 77.000 falle in nove mesi
L'Agenzia per la Cybersicurezza Nazionale pubblica ogni mese un riepilogo con il numero di nuove vulnerabilità registrate nel mondo dal programma CVE, il catalogo pubblico che assegna un codice a ogni falla. A settembre 2026 sono state 15.074, più del triplo delle 4.515 di settembre 2025. Nei primi nove mesi dell'anno sono oltre 77.000. L'ACN parla di una «crescita senza precedenti», arrivata mentre i modelli AI di frontiera riducono il tempo che serve per analizzare il codice, cercare vulnerabilità e preparare le prove di sfruttamento.20
Nuove vulnerabilità registrate nel mondo, mese per mese
Nello stesso mese il CSIRT Italia, la squadra operativa dell'ACN, ha individuato 8.213 sistemi e servizi esposti a rischio e ha inviato 10.839 comunicazioni ad amministrazioni e imprese, anche in base alla legge 90 del 2024. Lo sfruttamento di vulnerabilità è stato il primo modo di entrare nei sistemi colpiti.20
La legge 90 riguarda le pubbliche amministrazioni centrali, le regioni, le città metropolitane, i comuni sopra i 100.000 abitanti, le aziende sanitarie locali e alcune società di trasporto pubblico. Quando l'ACN segnala loro una vulnerabilità specifica, devono applicare la soluzione indicata «senza ritardo e comunque non oltre quindici giorni dalla comunicazione». Chi non lo fa rischia una sanzione da 25.000 a 125.000 euro, salvo motivate esigenze tecnico-organizzative comunicate in tempo.21 Se la stima di Mandiant è giusta, in media l'attacco comincia prima ancora che la correzione esista. Quindici giorni sono un tetto, e spesso arrivano tardi.
Dall'11 settembre il Cyber Resilience Act europeo obbliga i produttori di prodotti con elementi digitali a segnalare le vulnerabilità già sfruttate: un primo avviso entro 24 ore, che arriva al CSIRT nazionale designato e all'ENISA, una notifica più completa entro 72 ore e un rapporto finale entro 14 giorni da quando la correzione è disponibile.22 L'ENISA ha aperto lo stesso giorno la piattaforma unica per queste segnalazioni.23
Che cosa ne penso
Penso che i numeri di Glasswing siano una buona notizia a metà. Trovare una falla prima dei criminali serve se poi qualcuno la chiude; altrimenti resta un elenco di porte aperte che, con la regola dei 90 giorni, prima o poi diventa pubblico.
PHP2Shell aggiunge un dettaglio che conta. Per trovare le due falle sono bastati un ricercatore e una settimana, per correggerle ci sono voluti settantuno giorni, e una delle due era stata intravista due anni prima senza che qualcuno avesse il tempo e l'accordo per chiuderla. La strozzatura sta nelle poche persone che tengono in piedi un software usato da due siti su tre.
Nel caso di Glasswing i soldi vanno soprattutto a chi cerca: fino a 100 milioni di dollari in crediti per usare il modello, 4 milioni per le organizzazioni che sostengono la sicurezza dell'open source. Ad Anthropic riconosco una scelta corretta: pubblica il registro con il numero delle correzioni, anche se quel numero non la mette in buona luce. Ma il rapporto tra le due cifre dice dove sta lo squilibrio.
La regola che vorrei vedere è semplice: chi usa l'AI per trovare falle nel codice di altri porta, insieme alla segnalazione, una correzione proposta e provata. La finale della DARPA dice che, almeno in un ambiente di prova, si può fare in meno di un'ora. Il manutentore deve comunque controllarla, ma il lavoro che gli resta è più breve.
Per le aziende e gli enti pubblici guarderei soprattutto a un numero: quanti giorni servono per chiudere una falla già sfruttata. Lo porterei in consiglio di amministrazione e in giunta, accanto al bilancio, perché è quello che decide quanto a lungo una porta resta aperta.
Da dove cominciare
Chi ha un sito WordPress o un negozio online ha una cosa da fare prima di tutto il resto: chiedere al fornitore di hosting quale versione di PHP usa il sito. Deve essere una di quelle corrette il 21 ottobre (8.2.35, 8.3.36, 8.4.27 o 8.5.12) o una successiva, con le misure indicate dall'ACN per la terza falla. Se il sito gira su PHP 7 o su una versione ancora più vecchia, l'unica correzione è passare a una versione supportata.
Per un'azienda media o un ente locale partirei da quattro passi. Nessuno richiede un modello AI.
- InventarioSapere che cosa è espostoUn elenco aggiornato di server, apparati per l'accesso remoto, siti e plugin raggiungibili da internet. Un alert serve solo a chi sa di avere quel prodotto.
- PrioritàPrima le falle già sfruttateIl catalogo KEV della CISA e gli alert del CSIRT Italia dicono quali falle gli attaccanti stanno già usando. Quelle si chiudono in giorni, le altre possono seguire il ciclo normale.
- AutomaticoAggiornare senza aspettareAggiornamenti automatici dove si può, per sistemi operativi, browser e CMS. Dove non si può, una finestra di manutenzione fissa ogni settimana.
- ContrattiTempi di correzione per iscrittoChiedere ai fornitori per quanti anni garantiscono gli aggiornamenti e in quanti giorni rilasciano una correzione critica. Se non sanno rispondere, è un rischio da mettere a bilancio.
Il primo dato da raccogliere è interno: quanti giorni sono passati, l'ultima volta, tra un alert del CSIRT Italia su un prodotto in uso e l'installazione della correzione. Va confrontato con i quindici giorni della legge 90 e con i meno sette della stima di Mandiant.