Tutti gli articoli

· 8 min di lettura

Un’AI ha trovato un buco nascosto da più di dieci anni nel software di sette siti su dieci (e diversi governi hanno staccato la spina).

La finestra di un sito spento, con il simbolo di accensione, la scritta «In manutenzione» e una crepa che la attraversa. Accanto, una colonna di dieci caselle con sette accese, segnata «7 su 10». A destra la scritta «PHP · 21 ottobre 2026», il titolo «Un buco in 7 siti su 10.» e sotto «L’ha trovato un’AI. E diversi governi hanno spento i loro siti».

Mercoledì 21 ottobre un pezzo dell’internet europeo si è spento. Non l’ha fatto cadere un attacco: l’hanno spento apposta, per prudenza. In Germania il ministero per il digitale ha tolto dalla rete alcuni siti, in Francia il ministero dell’Interno ha disattivato quelli degli uffici amministrativi locali, e lo stesso hanno fatto le autorità di Belgio, Olanda, Finlandia e Repubblica Ceca. In Giappone il governo ha messo offline parti di alcuni siti «giusto per sicurezza», come ha spiegato il capo segretario di gabinetto Minoru Kihara.

Il motivo sta in due buchi trovati in PHP, un programma di cui forse non hai mai sentito parlare ma che usi tutti i giorni. Secondo W3Techs ci gira il 69% dei siti di cui si conosce la tecnologia, e Wiz, una delle aziende che hanno scoperto i buchi, arrotonda a sette siti su dieci nel mondo. Erano lì da più di dieci anni. A trovarli, quest’estate, sono stati ricercatori che lavoravano con l’intelligenza artificiale.

Ho letto la storia due volte. La prima come una notizia da tecnici, la seconda pensando a chiunque abbia un sito, dal negozio online al b&b, e anche a chi i siti li usa e basta. E alla fine c’è una domanda che conviene fare, già oggi, a chi ti gestisce il sito.

Il programma che non vedi

Quando apri un sito, dall’altra parte c’è un computer, il server, che prepara la pagina che ti arriva sul telefono. Su gran parte dei siti quel lavoro lo fa PHP. Ci girano anche WordPress, Drupal e Joomla, i programmi più usati per costruire siti senza scriverli da zero.

I due buchi stanno nel cuore di PHP. Per questo un sito può essere vulnerabile anche se è fatto benissimo: basta che giri su una versione non aggiornata. Wiz scrive che ogni versione di PHP uscita nell’ultimo decennio ha almeno uno dei due problemi.

Cosa ci può fare un malintenzionato? Due cose, e nessuna richiede una password. Può mandare al server una richiesta costruita apposta e fargli eseguire i suoi comandi: da lì può rubare i dati del sito, cambiarne le pagine o lasciarsi dentro una porta sul retro per tornare quando vuole. Oppure può leggere pezzi della memoria del server, dove a volte passano password, chiavi di accesso e certificati, del sito o di chi lo sta usando in quel momento.

L’Agenzia per la cybersicurezza nazionale li ha classificati come critici, con un punteggio di 9,2 su 10. Wiz si spinge più in là: sono tra i più gravi mai scoperti in PHP, «e forse nella storia del software».

Schema da sinistra a destra. Un telefono chiede una pagina; il server la prepara con PHP e la rimanda indietro. Dentro PHP, evidenziati, due buchi. Sotto, una barra piena al 69%: i siti che girano su PHP tra quelli di cui si conosce la tecnologia, secondo W3Techs. In fondo la scritta: ogni versione di PHP dell’ultimo decennio ha almeno uno dei due buchi.
Fig. 01 Il buco sta nel programma su cui gira la maggior parte dei siti: basta una versione vecchia per essere esposti.

Dieci anni sotto gli occhi di tutti

Adesso la parte che mi ha colpito di più. PHP è un progetto aperto: il suo codice lo può leggere chiunque, e in questi anni l’hanno letto in tantissimi. Eppure quei buchi sono rimasti lì.

Li hanno trovati in due, a pochi giorni di distanza. Calif, un’azienda di sicurezza ingaggiata da OpenAI per un programma che cerca falle nel software aperto (si chiama «Patch the Planet», più o meno «rattoppa il pianeta»), ne ha trovato uno con GPT-5.6 Sol e l’ha segnalato l’11 agosto. Wiz, l’azienda di sicurezza che fa parte di Google, ha trovato gli altri con un suo agente AI, con Gemini 4 Argon e ancora con GPT-5.6 Sol, e li ha segnalati il 24 agosto. Poi sono serviti due mesi di lavoro in silenzio con gli sviluppatori di PHP, finché mercoledì 21 ottobre la correzione è uscita insieme all’annuncio.

Secondo Wiz, dimostrare che i buchi si potevano davvero sfruttare richiedeva una catena di passaggi al limite di quello che un ricercatore umano riesce a fare in pratica. OpenAI dice che l’AI sembra averli trovati prima di chiunque volesse usarli male, e la considera una delle questioni di sicurezza più gravi degli ultimi tempi.

Per una volta, quindi, una notizia su AI e sicurezza comincia bene: le macchine hanno trovato il problema prima dei ladri. Il resto della storia spiega perché, nonostante questo, mercoledì in tanti hanno preferito spegnere.

Una linea del tempo. Più di dieci anni con i buchi nascosti in PHP. 11 agosto: Calif, al lavoro per OpenAI, segnala il primo buco trovato con GPT-5.6 Sol. 24 agosto: Wiz segnala gli altri, trovati con il suo agente AI, Gemini 4 Argon e GPT-5.6 Sol. 21 settembre: gli sviluppatori di PHP confermano e preparano la correzione. 21 ottobre, evidenziato: escono la correzione e l’annuncio, e diversi governi spengono i loro siti.
Fig. 02 Dieci anni di silenzio, due mesi di lavoro riservato, poi la correzione.

Il giorno in cui si spegne tutto

Quando una falla diventa pubblica comincia una gara: da una parte chi aggiorna i propri server, dall’altra chi prova a entrare in quelli che non l’hanno ancora fatto.

E stavolta la gara era più corta del solito. Wiz avverte che adattare un attacco alle tante versioni e configurazioni di PHP una volta era un ostacolo serio, e che «con l’AI non lo è più». Le agenzie di sicurezza americane hanno consigliato di spegnere i siti che non si potevano aggiornare subito (l’FBI secondo AP, la NSA secondo TechCrunch e Al Jazeera), e la stessa indicazione l’ha data la nostra Agenzia per la cybersicurezza nazionale. Nelle ore dopo l’annuncio Matthew Prince, il capo di Cloudflare, una delle aziende che proteggono i siti dagli attacchi, ha parlato di «milioni» di tentativi di sfruttare la falla.

Ecco perché i governi hanno staccato la spina: un sito spento non si può attaccare. La premier giapponese Sanae Takaichi l’ha detto senza giri di parole: se aggiornare è difficile, sospendere un sito è un modo efficace per ridurre il rischio.

Una cosa va detta chiara, perché in giro si legge di tutto. Finora nessuno ha confermato siti violati o dati rubati attraverso questi buchi, e il governo giapponese dice di non aver ricevuto segnalazioni di danni. Le pagine «in manutenzione» di questi giorni sono il segno che qualcuno ha preso la cosa sul serio.

Una fila di siti spenti, ognuno con il nome del Paese: Germania, Francia, Belgio, Olanda, Finlandia, Repubblica Ceca, e Giappone con parti di siti spente. Accanto, un contatore: «milioni» di tentativi di sfruttare i buchi nelle prime ore, secondo Cloudflare. Sotto, evidenziato: nessun sito violato confermato.
Fig. 03 Spegnere un sito è il modo più semplice per non farlo attaccare mentre si aggiorna.

La stessa AI, dall’altra parte

La PHP Foundation, che si occupa del progetto, ha scritto una frase che secondo me vale più di tutto il resto: gli strumenti trovano i bug più in fretta che mai, per chi difende e per chi attacca, e le segnalazioni continueranno ad aumentare.

Questa volta le AI migliori le avevano in mano OpenAI, Google e chi lavora con loro, e le hanno usate per chiudere la porta. Ma un’AI che legge il codice e trova il punto debole la può usare anche qualcun altro, e quel qualcuno non avvisa nessuno prima. Io mi aspetto altre giornate come quella di mercoledì: buchi vecchi di anni che saltano fuori, e aggiornamenti da fare in fretta.

Per un’azienda grande vuol dire avere qualcuno capace di aggiornare i server nel giro di poche ore. Per una piccola vuol dire una cosa più semplice, che però spesso nessuno ha mai fatto: sapere chi si occupa del proprio sito.

Se hai un sito, anche piccolo

Il negozio online, o il sito del b&b fatto anni fa da un amico: se gira su WordPress o su un altro sistema scritto in PHP, il problema ti riguarda. La buona notizia è che non devi diventare un tecnico.

Manda una mail, o fai una telefonata, a chi ti gestisce il sito o all’hosting, cioè l’azienda che lo tiene acceso sui suoi server. Chiedi se PHP è stato aggiornato a una delle versioni corrette, la 8.5.12, la 8.4.27, la 8.3.36 o la 8.2.35, e se l’aggiornamento è stato installato davvero, non solo messo in programma.

Ci sono due trappole da conoscere. Aggiornare WordPress o i suoi plugin non aggiorna PHP: sono due cose diverse, e la seconda spesso la deve fare l’hosting. E se il tuo sito gira su PHP 8.1 o su una versione ancora più vecchia, la correzione ufficiale non arriverà, perché quelle versioni non sono più seguite: serve una soluzione del fornitore oppure il passaggio a una versione recente. Non è un caso raro: secondo i dati di W3Techs riportati da PhoneToday, circa un sito PHP su tre gira ancora sulle versioni 5 o 7.

Se il sito sta su un hosting gestito o su una piattaforma cloud che ha già applicato la correzione, sei a posto. Per chi segue la parte tecnica, il CERT-AgID ha segnalato anche uno strumento di OpenAI che confronta la versione di PHP dichiarata da un sito con quelle corrette, senza provare ad attaccarlo.

E se i siti li usi e basta? Sul telefono e sul computer non c’è niente da installare: PHP gira sui server dei siti. Un sito in manutenzione non vuol dire che sia stato violato. I consigli di Malwarebytes sono quelli del buon senso: diffida dei download che non hai chiesto, delle pagine che ti portano altrove e delle richieste di accesso ripetute, anche sui siti che conosci bene, e se qualcosa ti sembra strano chiudi la pagina.

Due colonne. A sinistra, «Se hai un sito»: chiedi all’hosting se PHP è aggiornato a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, installato e non solo programmato; aggiornare WordPress non aggiorna PHP; con PHP 8.1 o più vecchio la correzione ufficiale non c’è. A destra, «Se i siti li usi e basta»: niente da installare su telefono e computer; un sito in manutenzione non vuol dire violato; diffida di download non chiesti, pagine che ti portano altrove e richieste di accesso ripetute.
Fig. 04 Chi ha un sito ha una mail da mandare. Chi naviga, solo un po’ di attenzione in più.

Quello che voglio lasciarti

Questa storia mi lascia due sensazioni insieme. La prima è meraviglia: un’AI ha visto, in un programma che fa girare la maggior parte dei siti del mondo, quello che a nessuno era saltato all’occhio per più di dieci anni, e chi l’ha trovato ha scelto di avvisare e di riparare. La seconda è più scomoda: strumenti come quelli sono alla portata di tanti, e le prossime volte la gara tra chi chiude e chi prova a entrare sarà ancora più corta.

Non serve avere paura di internet. Serve sapere chi tiene in ordine il pezzo che è tuo.

E tu, se hai un sito, anche piccolo, sapresti dire chi lo aggiorna?

Le informazioni vengono dagli avvisi dell’Agenzia per la cybersicurezza nazionale e del CERT-AgID, dal blog di Wiz e dagli articoli di AP, TechCrunch, Al Jazeera, Malwarebytes e PhoneToday del 21 e 22 ottobre: i link sono qui sotto.

Marco CEO@Neuracy

Fonti