Per oltre dieci anni una crepa è rimasta nascosta nel motore di PHP, il linguaggio di sette siti web su dieci. Nell’estate 2026 ricercatori e modelli di IA l’hanno trasformata in un attacco funzionante. Il 21 ottobre mezza Europa istituzionale si è spenta per prudenza. Resta una domanda: chi ripara le falle che scopre l’IA?

Immagine di repertorio.

C’è una metafora che aiuta a capire che cosa sia successo. Pensate a una città in cui gran parte degli edifici è stata costruita con la stessa trave d’acciaio, prodotta dallo stesso fornitore. Per vent’anni quella trave ha retto senza un cedimento. Poi, un giorno, un gruppo di ingegneri scopre che, sotto un carico molto particolare e in un istante preciso, può spezzarsi. Non tutti i palazzi crolleranno, ma ogni amministratore di condominio deve correre a controllare il proprio.

PHP è quella trave. E PHP2Shell, il nome con cui i ricercatori di Wiz hanno battezzato la scoperta, è la crepa che nessuno aveva analizzato fino in fondo. La differenza rispetto al passato è che, questa volta, a illuminarla non sono stati soltanto occhi umani: accanto ai ricercatori lavoravano alcuni dei modelli di intelligenza artificiale più avanzati al mondo.

Una minaccia nel cuore di Internet

PHP è un linguaggio di programmazione nato a metà degli anni Novanta per costruire pagine web dinamiche e da allora non ha mai smesso di crescere. Ci girano sopra piattaforme molto note come WordPress, Drupal, Joomla e MediaWiki, il software di Wikipedia. Ci girano sopra negozi online, portali bancari, siti di testate giornalistiche e un’infinità di servizi della pubblica amministrazione.

I numeri danno le vertigini. Secondo W3Techs, al 23 ottobre 2026 PHP è usato dal 69,3% dei siti web di cui si conosce il linguaggio lato server. Wiz arrotonda al 70%, ed è da qui che nasce il titolo, rimbalzato ovunque, di una falla che «colpisce il 70% di Internet». Il dato va però letto con attenzione: misura quanto è diffuso PHP, non quanti siti siano effettivamente vulnerabili o, tantomeno, violati.

Il 21 ottobre 2026 il progetto PHP ha pubblicato aggiornamenti d’emergenza per due vulnerabilità, CVE-2026-109618 e CVE-2026-109619, entrambe valutate 9,2 su 10 nella scala CVSS v4.0. In determinate condizioni permettono a un aggressore di eseguire codice sul server senza password né account: è la cosiddetta Remote Code Execution (RCE), il tipo di falla più temuto da chi difende sistemi esposti su Internet. Chi la sfrutta può rubare dati, alterare contenuti, installare malware o usare il server come trampolino verso altre macchine.

Wiz ha documentato anche un secondo effetto, meno spettacolare ma insidioso: la possibilità di leggere porzioni della memoria del server, dove possono trovarsi password, token di autenticazione, chiavi API e certificati appartenenti ad altri utenti. Un meccanismo che i ricercatori paragonano esplicitamente a Heartbleed, la falla di OpenSSL che nel 2014 fece tremare mezzo Web.

Non tutti i siti PHP sono automaticamente a rischio allo stesso modo: l’esposizione reale dipende dalla versione installata, dalla configurazione del server e dalla rapidità con cui si applicano le patch. Ma secondo Wiz ogni versione di PHP pubblicata nell’ultimo decennio, fino alla 5.4, è toccata da almeno uno dei difetti. E proprio qui sta la novità della vicenda: non solo nella gravità tecnica, ma nel modo in cui l’intelligenza artificiale ha trasformato un difetto noto ma ritenuto quasi inattaccabile in un’arma concreta.

Le radici: un campanello d’allarme già nel 2024

Questa storia non comincia ad ottobre 2026, ma nel 2024 quindi ben due anni prima. Nel 2024 infatti, PHP si sottopone al primo audit di sicurezza esterno dopo anni. A finanziarlo è il Sovereign Tech Agency, l’agenzia tedesca che sostiene il software open source di interesse pubblico; a organizzarlo è l’OSTIF; a eseguirlo è la società francese Quarkslab. Mentre corregge uno dei problemi segnalati da Quarkslab, uno sviluppatore del nucleo di PHP, pagato dalla PHP Foundation, nota qualcosa di strano: i primi indizi di un difetto nel modo in cui il motore gestisce l’esaurimento della memoria. Si ipotizza che possa essere sfruttato, ma nessuno trova un percorso concreto per farlo da remoto. In quel momento altre falle, più evidenti e con un impatto chiaro, passano davanti nella lista delle priorità.

Il problema è che correggerlo non è affatto semplice. Il team di sicurezza elabora diverse soluzioni, ciascuna con un prezzo da pagare: alcune rompono la compatibilità con il codice esistente, altre aprono nuove possibilità di attacchi di tipo denial of service, altre ancora richiederebbero di modificare decine di estensioni di terze parti, un coordinamento che appare impossibile. Immaginate i costi da simili revisioni. Il gruppo, a questo punto, decide per consenso, teme le conseguenze di una scelta sbagliata ed è composto da pochissime persone che conoscono a fondo il motore, già sommerse da altre responsabilità. Il lavoro si blocca e riparte più volte, per mesi.

Il 21 ottobre 2026 la PHP Foundation ammette il ritardo definendolo un «fallimento strutturale», figlio sia del processo decisionale del team sia della mancanza di risorse. Da allora le regole sono cambiate: le decisioni si possono prendere a maggioranza e i compromessi vengono incoraggiati. È una lezione che vale ben oltre PHP. Sapere che esiste una debolezza non basta: bisogna capirne fino in fondo le conseguenze e avere le persone, il tempo e il denaro per ripararla prima che venga sfruttata per intenti malevoli.

Estate 2026: entrano in scena i ricercatori e l’IA

Il punto di svolta arriva quando la PHP Foundation fa entrare il progetto in Patch the Planet, il programma con cui OpenAI mette a disposizione modelli e competenze per scovare e correggere falle nel software più diffuso. Il 30 luglio 2026 la società di sicurezza Calif avvia un audit di PHP.

Bastano dodici giorni per recuperare ciò che in passato aveva richiesto mesi. L’11 agosto Ryan Austin, ricercatore di Calif (indicato come «Ryan A» nel resoconto della Foundation), lavorando con GPT-5.6 Sol, uno dei modelli più avanzati di OpenAI, segnala un’esecuzione di codice da remoto “incondizionata”. La causa è la stessa anomalia intravista nel 2024. Questa volta, però, c’è la prova che può essere trasformata in un attacco reale. OpenAI, con il proprio team Codex Security, individua indipendentemente la stessa radice del problema e il 18 settembre aggiunge ulteriori vettori d’attacco.

In parallelo, e in modo del tutto indipendente, si muove Wiz Research. Il 19 agosto il gruppo israelo-americano individua la prima falla combinando tre strumenti: Gemini 4 Argon di Google DeepMind, GPT-5.6 Sol e Wiz Atlas, il proprio ricercatore di vulnerabilità basato su IA. Il 20 agosto dimostra un attacco senza autenticazione contro Drupal, il 21 contro WordPress. In seguito anche Joomla cade nella stessa rete. Il 24 agosto Wiz consegna tutto al team di sicurezza di PHP. Secondo i ricercatori, è stato soprattutto Gemini 4 Argon a dare un contributo decisivo, dalla scoperta allo sviluppo dell’exploit fino alla verifica della patch.

Non è stata un’intelligenza artificiale, da sola, a scoprire e risolvere tutto.

Da quel momento chiudere la falla diventa la priorità assoluta per tutto il personale dedicato alla sicurezza, che lavora a tempo pieno, nei fine settimana e a ciclo continuo. Nel frattempo si forma una coalizione che ha avuto circa due mesi per preparare correzioni, protezioni e indicazioni prima della divulgazione pubblica. Vale la pena fermarsi su un punto, perché smonta una narrazione troppo comoda. Non è stata un’intelligenza artificiale, da sola, a scoprire e risolvere tutto. Le prime tracce del difetto le aveva trovate un essere umano nel 2024. Sono stati ricercatori in carne e ossa, assistiti da modelli diversi di aziende concorrenti, a condurre le analisi, verificare i risultati e collaborare con gli sviluppatori. E la patch l’hanno scritta i manutentori di PHP. Ma senza quei modelli, quella dimostrazione forse sarebbe arrivata molto più tardi. O sarebbe arrivato prima qualcun altro con fini diversi.

C’è infine un dettaglio poco raccontato: non è stata solo OpenAI. All’inizio del 2026 la Foundation aveva già analizzato PHP con Claude Mythos di Anthropic, tramite il progetto Alpha-Omega, e successivamente aveva aggiunto Daybreak Red di OpenAI per validare segnalazioni ed exploit. Più di recente anche Trail of Bits ha avviato un proprio audit. PHP, insomma, è diventato un banco di prova per l’intera industria dell’IA applicata alla sicurezza.

Quanto ha accelerato l’IA? Quello che sappiamo e quello che no

È la domanda che rende questa vicenda così interessante, ed è anche quella su cui è più facile scivolare nell’enfasi. Partiamo da alcuni fatti. Calif ha presentato la segnalazione dodici giorni dopo l’inizio dell’audit. Wiz è passata dalla prima scoperta a un attacco funzionante contro Drupal in ventiquattro ore, e contro WordPress in quarantotto. Un difetto che nel 2024 nessuno era riuscito a trasformare in un attacco remoto è diventato, nell’arco di poche settimane, un exploit capace di colpire le tre piattaforme più diffuse del Web.

Wiz si spinge più in là. Secondo i suoi ricercatori, costruire l’attacco richiedeva di concatenare più difetti e di adattarsi alla disposizione della memoria di ogni singolo bersaglio, un lavoro di tentativi ed errori ai limiti di ciò che un esperto umano riesce a fare in tempi ragionevoli. Con i modelli di frontiera, scrivono, un singolo ricercatore ha completato in una settimana quello che prima avrebbe richiesto mesi a un team di livello mondiale, e gli exploit sono stati adattati alle diverse applicazioni nel giro di ore.

È una stima autorevole. Tuttavia, resta una stima che viene da un’azienda che vende prodotti di sicurezza basati sull’IA. Alcuni dati potrebbero essere enfatizzati per rendere il tutto molto più accattivante. Non esistendo un esperimento controllato, nel quale due gruppi affrontano lo stesso problema, uno con l’IA e uno senza, non possiamo stabilire una stima reale delle tempistiche. Sarebbe quindi scorretto quantificare l’accelerazione con precisione. Ciò che è documentato, da fonti indipendenti tra loro, è che l’IA ha avuto un ruolo sostanziale sia nella scoperta sia nella dimostrazione dello sfruttamento della vulnerabilità.

C’è poi un effetto collaterale che i numeri della PHP Foundation rendono evidente. Dal 1° luglio 2026 il team di sicurezza ha pubblicato 15 CVE e ha dovuto esaminare oltre cento segnalazioni rivelatesi non valide, duplicate o non riproducibili. L’IA genera scoperte, ma genera anche rumore. E ogni segnalazione, giusta o sbagliata, finisce sulla scrivania di un piccolo gruppo di persone. Ogni decisione e ogni patch passano da un essere umano.

Ciò che è emerso chiaramente è che un software usato e controllato per decenni può nascondere debolezze che solo ora diventiamo capaci di comprendere fino in fondo. È una buona notizia per chi difende i sistemi. Può diventare una pessima notizia se gli stessi strumenti accelerano il lavoro di chi attacca.

Come funziona, spiegato senza tecnicismi

Per capire PHP2Shell bisogna sapere una cosa su come lavora un server PHP. Non c’è un programma nuovo per ogni visitatore: ci sono dei «lavoratori» (i worker) che restano accesi e servono una richiesta dopo l’altra. Finita una pagina, il worker fa pulizia della memoria usata e passa alla successiva. Immaginiamo ora un archivio. Ogni richiesta apre dei fascicoli, li usa e alla fine li restituisce. Il registro dell’archivio annota quali fascicoli sono in uso e quali sono liberi. Tutto funziona finché il registro dice la verità.

PHP2Shell nasce da un momento preciso: quello in cui PHP esaurisce la memoria che gli è concessa (il cosiddetto memory_limit) e interrompe di colpo l’operazione in corso. Se lo stop arriva nell’istante sbagliato, il registro resta sporco. Nel primo caso (CVE-2026-109618) restano in giro dati inizializzati a metà, che il programma poi tratta come validi. Nel secondo (CVE-2026-109619) un’annotazione continua a indicare un fascicolo che è già stato restituito e magari riassegnato a qualcun altro. È quello che gli esperti chiamano use-after-free: usare memoria dopo averla liberata.

Un aggressore abile può provocare deliberatamente quell’esaurimento di memoria con una richiesta costruita ad arte, poi inviare una seconda richiesta allo stesso worker e «riempire» il fascicolo orfano con contenuti scelti da lui. A quel punto il programma, fidandosi del registro, esegue ciò che trova. Wiz ha documentato quattro varianti di questo schema:

• Il gestore dell’avanzamento degli upload: una funzione che mostra a che punto è il caricamento di un file può lasciare dietro di sé dati di sessione corrotti, sfruttabili per prendere il controllo di WordPress, Drupal e Joomla.
• La fuga di memoria via cookie: lo stesso meccanismo può far sì che il server restituisca all’aggressore, dentro il cookie di sessione PHPSESSID, frammenti di memoria contenenti dati di altri utenti. Funziona anche se il sito non usa affatto le sessioni.
• La traccia degli errori fatali: PHP conserva il resoconto dell’ultimo errore grave; se la memoria si esaurisce, quel resoconto può puntare a memoria già liberata. Dimostrato contro Drupal.
• La cache OPcache: il componente che velocizza PHP memorizzando il codice già compilato può confondere il tipo di un oggetto con un altro, corrompendo uno stato condiviso tra più worker. Dimostrato contro WordPress.

Il punto più preoccupante è che il difetto vive proprio nel motore, non nelle sue applicazioni. Un sito WordPress perfettamente aggiornato, con plugin e tema impeccabili, resta vulnerabile se il PHP sottostante non è stato corretto. La configurazione più a rischio è Apache con il modulo mod_php: qui, secondo l’avviso ufficiale, una richiesta anonima può innescare l’attacco prima ancora che parta il codice dell’applicazione, con le impostazioni predefinite. Su PHP-FPM, la configurazione oggi più comune, l’esecuzione di codice è stata confermata attraverso percorsi che passano per l’applicazione. Sono coinvolti anche php-cgi, FrankenPHP e LiteSpeed.

C’è infine una conseguenza pratica per chi difende: questi attacchi avvengono sotto il livello dell’applicazione, quindi i log del sito possono dire pochissimo. Wiz suggerisce di cercare richieste multipart insolite seguite da errori di limite di memoria o da raffiche di errori HTTP 500, cookie PHPSESSID anomali per dimensione o formato e riavvii inspiegabili dei worker.

Quarantotto ore convulse: la fuga di notizie e l’allarme mondiale

Per due mesi la divulgazione coordinata funziona come da manuale. Il piano prevede il rilascio delle patch per giovedì 22 ottobre alle 14:00 UTC. Poi, a quarantotto ore dal traguardo, qualcosa si rompe.

Martedì 20 ottobre, ore 15:00 UTC circa. I due identificativi CVE cominciano a circolare su forum e social. Un post su Hacker News, poi cancellato, parla di due falle con punteggio 10.0 che colpiscono PHP fin dalla versione 5. Il punteggio è sbagliato, ma le falle sono vere: la società di sicurezza watchTowr conferma pubblicamente che esistono, senza rivelarne i dettagli.

Ore 19:30 UTC. Il progetto PHP anticipa il preavviso ufficiale e sposta il rilascio di un giorno, a mercoledì 21 alle 14:00 UTC. Rilasciare subito avrebbe lasciato molti utenti senza un pacchetto pronto da installare: i distributori Linux stavano ancora preparando gli aggiornamenti. Un giorno è il compromesso tra rapidità e ordine. In serata CERT-EU pubblica l’avviso 2026-018 e invita a prepararsi a un aggiornamento immediato.

Ore 20:00 UTC circa. Calif, una delle società che avevano segnalato le falle, pubblica per errore un video che mostra il proprio attacco funzionare contro diversi bersagli, rivelando qualche dettaglio in più. Il video viene rimosso, ma le copie corrono già sui social. Secondo la PHP Foundation, quel filmato ha accelerato lo sviluppo di diversi exploit dimostrativi. Anche le indicazioni di mitigazione inviate in via riservata ad alcuni operatori di infrastrutture critiche potrebbero essere trapelate.

Mercoledì 21 ottobre, ore 07:41 UTC. Il colpo più duro alla strategia di divulgazione arriva da Chainguard, fornitore di immagini container, che rompe unilateralmente l’embargo pubblicando versioni già corrette più di sei ore prima del rilascio ufficiale. Chiunque, aggressori compresi, può ora studiare la patch e risalire al difetto mentre il resto del mondo aspetta. La Foundation parla apertamente di settimane di lavoro di molte parti ignorate.

Ore 14:00 UTC. Escono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Per i rami non più supportati 7.4, 8.0 e 8.1 il team pubblica, in via eccezionale, correzioni minime da compilare a mano.

Nel giro di poche ore si mobilitano le autorità di mezzo mondo. In Europa la Commissione (DG CNECT), ENISA, CERT-EU, Europol EC3 e la rete dei CSIRT nazionali firmano una dichiarazione congiunta: individuare le applicazioni PHP, coordinarsi con i fornitori di hosting, aggiornare partendo dai sistemi esposti e, se non è possibile, isolarli dalla rete pubblica. ENISA segnala anche un dettaglio spesso trascurato: molti prodotti commerciali usano PHP «sotto il cofano» senza dichiararlo, e il CSIRT olandese NCSC-NL ha avviato un elenco pubblico dei software di terze parti coinvolti. E ricorda che dall’11 settembre 2026, con il Cyber Resilience Act, i produttori di software devono notificare le vulnerabilità sfruttate attivamente.

Negli Stati Uniti la NSA, insieme all’FBI secondo un avviso diffuso agli ospedali americani, si spinge oltre: chi non può aggiornare subito dovrebbe spegnere il sistema. L’avviso aggiunge un monito spesso dimenticato: se un sistema è stato compromesso prima della patch, aggiornarlo non basta a cacciare l’intruso. In Australia l’ACSC emette un’allerta critica.

In Italia il CERT-AGID pubblica il 21 ottobre una guida operativa per le pubbliche amministrazioni, con un avvertimento molto concreto: attenzione agli enti che usano il tema Drupal per i siti dei Comuni (design-comuni-drupal-theme) nella versione 1.8.1 o precedenti, basato su Drupal 9. E ricorda che aggiornare il solo CMS o i plugin non corregge l’interprete PHP sottostante.

Una lezione chiara. Non basta conoscere una vulnerabilità: è necessario decidere come e quando comunicarla, dando ai difensori il tempo di proteggersi senza regalare vantaggi ad eventuali aggressori. In questo caso è bastato un post anonimo, un video caricato per sbaglio e un fornitore impaziente per accorciare quella finestra di rientro.

Che cosa è successo davvero ai siti Internet?

Mercoledì 21 ottobre una parte del Web istituzionale europeo si è spenta da sola. Nessun attacco, prudenza. Secondo una ricostruzione di Reuters, il governo olandese ha oscurato in via precauzionale numerosi siti, tra cui il portale Overheid.nl, il Porto di Rotterdam, la federazione calcistica KNVB, i siti dei cinque maggiori partiti e molti ospedali; anche il centro nazionale di cybersicurezza NCSC ha messo offline il proprio sito.

In Germania il fornitore IT federale ITZBund ha spento diversi portali, compreso per alcune ore quello della polizia federale BKA, e in Assia la cancelleria regionale ha sospeso le pagine del governo del Land. L’ufficio federale BSI ha emesso un’allerta di livello «arancione» e ha raccomandato, nel dubbio, di staccare i server dalla rete. In Francia sono stati sospesi i siti delle prefetture e il portale governativo info.gouv.fr; in Belgio quelli del ministero degli Esteri; misure analoghe sono state adottate in Finlandia. Negli Stati Uniti la Casa Bianca ha avviato una valutazione dei possibili impatti.

È il paradosso di PHP2Shell: prima ancora che gli aggressori facessero danni, la sola minaccia ha tolto ai cittadini l’accesso a servizi pubblici per ore. Spegnere un sito riduce il rischio, ma il costo è reale. E gli attacchi veri? Qui conviene distinguere tre cose diverse: un sistema vulnerabile, un tentativo di attacco e una compromissione riuscita.

I tentativi ci sono stati, e presto. Cloudflare aveva preparato regole di protezione già da inizio ottobre e le ha attivate per tutti i clienti, compresi quelli gratuiti, alle 03:02 UTC del 21 ottobre, circa nove ore prima della divulgazione. Ha poi osservato traffico malevolo diretto contro i propri clienti e aggressori che modificavano il contenuto degli attacchi per aggirare i filtri. Per bloccarli ha messo in campo per la prima volta una tecnologia che analizza insieme la richiesta e la risposta del server. Anche Fastly e watchTowr hanno riferito di tentativi di sfruttamento, e su forum clandestini sono comparse discussioni in cui criminali si scambiavano exploit, lamentando che non funzionassero su tutte le versioni, secondo SOCRadar.

Le compromissioni accertate restano poche e frammentarie. Al momento del rilascio il team di sicurezza PHP non aveva individuato exploit pubblici funzionanti tra quelli circolati dopo la fuga di notizie. Il 21 ottobre la CISA statunitense non aveva ancora inserito le due falle nel proprio catalogo delle vulnerabilità sfruttate attivamente, mentre la società Patchstack dichiarava di aver confermato diversi incidenti. Il centro belga per la cybersicurezza non aveva registrato attacchi contro siti nazionali e l’agenzia australiana ACSC non era a conoscenza di sfruttamenti attivi.

Al 23 ottobre 2026 non esiste dunque un bilancio mondiale verificato dei server compromessi tramite PHP2Shell. Non è corretto affermare che il 70% dei siti sia stato violato, né che sia in corso una compromissione generalizzata. C’è però un numero che fa riflettere. Secondo un conteggio basato su Shodan diffuso il 20 ottobre e ripreso da CybelAngel, sono circa 2,24 milioni i server PHP direttamente esposti su Internet (si contano macchine, non siti o organizzazioni) e il 59% di questi gira su versioni che non riceveranno alcuna correzione ufficiale. È lì, nella lunga coda di server dimenticati, che si giocherà la partita delle prossime settimane.

Dagli ospedali alla geopolitica: quando una falla diventa questione nazionale

Ospedali, operatori energetici, trasporti, banche e amministrazioni pubbliche erogano servizi essenziali attraverso sistemi informatici. Una parte di questi sistemi parla PHP: portali per i cittadini, prenotazioni, aree riservate, pannelli di gestione, intranet. Non è un caso che l’avviso di FBI e NSA sia stato rilanciato dall’associazione degli ospedali americani, né che nei Paesi Bassi siano stati proprio molti siti ospedalieri a essere spenti per precauzione.

Va specificato che una falla in uno di questi componenti non consegna automaticamente le chiavi dell’intera infrastruttura. Compromettere il sito di una società elettrica non significa controllare la rete elettrica. Sappiamo però che un server violato è una porta d’ingresso. PHP2Shell rende quella porta particolarmente preziosa per un motivo specifico: la fuga di memoria documentata da Wiz può esporre password, token e chiavi API. Se il server web custodisce le credenziali per accedere a un database, a un servizio cloud o a un sistema interno, l’aggressore può usarle per spostarsi altrove. Per questo diversi analisti, raccomandano di ridurre al minimo i privilegi concessi ai server PHP e di sorvegliare la comparsa di processi anomali avviati dal web server.

Immaginiamo un’azienda sanitaria il cui portale prenotazioni giri su una versione vulnerabile. Nel caso migliore, un attacco renderebbe il servizio indisponibile. Nel caso peggiore, se il portale fosse collegato senza adeguate separazioni ai sistemi interni, potrebbe diventare il primo anello di una catena che arriva ai dati dei pazienti. La gravità dipenderebbe dalle autorizzazioni, dalla segmentazione delle reti e dalle difese effettivamente in campo. È esattamente per questo che la protezione delle infrastrutture critiche insiste sulla separazione tra le reti amministrative e i sistemi che controllano processi fisici: il pericolo vero raramente è una singola falla, quasi sempre è la concatenazione di più debolezze.

E se fosse finita nelle mani di uno Stato ostile?

Una domanda legittima. Gli attacchi informatici non servono solo a estorcere denaro: sono strumenti di spionaggio, di sabotaggio e di influenza. Un attore statale ben organizzato potrebbe usare una falla come questa per mappare i sistemi pubblici vulnerabili di un Paese, entrare nei server, raccogliere credenziali e muoversi verso informazioni di interesse strategico. Oppure potrebbe colpire un fornitore che gestisce servizi per decine di enti, sfruttandolo come trampolino verso i suoi clienti.

Sono scenari tecnicamente plausibili. In questo specifico caso, governi e alleati sono stati coinvolti ben prima del pubblico. OpenAI ha dichiarato di aver lavorato con i partner per coinvolgere diverse agenzie del governo statunitense e partner internazionali. Il presidente di OpenAI, Greg Brockman, si è spinto a ipotizzare un futuro in cui difensori autorizzati, come i governi, scansionino Internet alla ricerca di server vulnerabili e, nei casi estremi, li correggano da remoto. Una proposta che apre nuovi interrogativi sulla sovranità, la responsabilità e anche la privacy.

Il contesto cambia e la criminalità informatica si adatta. A maggio 2026 Google ha documentato per la prima volta un gruppo criminale che sembrava aver usato l’IA per scoprire una falla sconosciuta e tentare un attacco su larga scala, secondo il New York Times. L’uso offensivo dell’IA nella caccia alle vulnerabilità non è più un’ipotesi da convegno: è una realtà con cui intelligence e difesa nazionale devono fare i conti.

L’IA, un’arma a doppio taglio

L’intelligenza artificiale renderà Internet più sicuro o più fragile? Per ora la risposta onesta è: entrambe le cose. La bilancia non ha ancora deciso da che parte pendere. Da un lato, PHP2Shell è una vittoria dei difensori. Dall’altro lato, la stessa OpenAI ha riconosciuto che questa capacità può aiutare gli aggressori a sviluppare rapidamente strumenti offensivi.

Molti ritengono che l’IA stia accorciando i tempi tra scoperta e sfruttamento e che nuove interruzioni siano probabili; ma più vulnerabilità scoperte non significano necessariamente, in proporzione, più attacchi riusciti. C’è chi, come il crittografo Matthew Green, si è spinto a ipotizzare che l’IA possa rendere il software così povero di difetti da complicare perfino le attività di hacking legale delle forze dell’ordine. E chi, come Hamid Kashfi di Xbow, ribatte che per ogni falla trovata con l’IA e segnalata ce ne sarebbero circa venti che restano nell’ombra.

Il risultato di lungo periodo potrebbe quindi essere un Internet più sicuro, ripulito da difetti rimasti nascosti per anni. Ma solo a una condizione: che la capacità di correggere tenga il passo con la capacità di scoprire. Ecco quindi l’anello debole. La sicurezza nazionale non dipende soltanto dalla capacità di respingere un attacco, ma dalla conoscenza e dalla manutenzione delle infrastrutture digitali che sostengono la vita quotidiana. L’intelligenza artificiale può diventare il più straordinario alleato dei difensori, ma il suo contributo sarà davvero positivo solo se istituzioni, aziende e gestori delle infrastrutture sapranno usarla con la stessa rapidità di chi attacca, e se qualcuno pagherà le persone che, alla fine, devono scrivere e rilasciare le correzioni. Il vero nocciolo della questione non è se l’IA scoprirà nuove vulnerabilità ma se saremo capaci di correggerle prima che qualcuno impari a sfruttarle.