Sicurezza informatica, quando l’AI trova le falle da sola

Il 21 ottobre 2026 il progetto Node.js ha pubblicato una release di sicurezza con dieci vulnerabilità corrette, quattro delle quali di gravità alta. Una di queste, la CVE-2026-111497 nel decoder Brotli, è stata segnalata da OpenAI Codex Security: uno strumento di intelligenza artificiale. Non una persona che leggeva codice, non un ricercatore che passava le notti su un debugger. Un sistema automatico che scandaglia codice sorgente e trova errori di gestione della memoria.

È una buona notizia. Ed è anche il motivo per cui, se gestisci un sito o un e-commerce, il modo in cui hai organizzato la manutenzione fino a oggi probabilmente non basta più.

Il caso PHP di ottobre 2026 è un esempio da manuale

Sempre il 21 ottobre 2026 sono uscite le correzioni per due vulnerabilità PHP, CVE-2026-109618 e CVE-2026-109619, battezzate dai ricercatori PHP2Shell. Sono due use-after-free che consentono a un attaccante non autenticato, cioè senza credenziali, senza account, senza niente, di eseguire codice sul server. Le versioni corrette sono PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Le versioni 8.1 e precedenti non ricevono più aggiornamenti dal progetto PHP: chi ci gira sopra non riceverà mai una patch.

Il 26 ottobre la CISA statunitense le ha inserite nel catalogo delle vulnerabilità sfruttate attivamente. Non “potenzialmente pericolose”: usate, nel mondo reale, contro server reali. Cinque giorni dopo la correzione. E secondo l’avviso del Centro canadese per la sicurezza informatica, una terza falla della stessa famiglia, la CVE-2026-115560, non era nemmeno coperta dalle correzioni del 21.

Perché questo caso riguarda praticamente ogni PMI italiana con un sito? Perché PHP è il linguaggio su cui gira WordPress, WooCommerce, buona parte dei gestionali web e dei portali aziendali costruiti negli ultimi quindici anni. Non è una tecnologia di nicchia per addetti ai lavori. È il motore sotto il cofano di quasi tutto.

Il numero italiano che dovrebbe far riflettere

Il 25 ottobre 2026 l’Agenzia per la cybersicurezza nazionale, attraverso il CSIRT Italia, ha diffuso una rilevazione sullo stato dei server italiani. Su 741.523 servizi PHP individuati, 285.149 usavano versioni potenzialmente vulnerabili. Rapportato ai servizi di cui è stato possibile identificare la versione, parliamo dell’81,9%. La gravità assegnata è 9,2 su 10, classificata critica. Il dato è riportato nella cronaca dell’allerta pubblicata da AGI.

Quattro server su cinque. Non è un problema di “aziende disattente” o di “imprenditori che non capiscono”. È la fotografia di un modo diffuso di gestire il digitale: il sito si fa una volta, poi resta lì. Finché funziona, nessuno lo guarda. E un sito che risponde alle richieste continua a sembrare sano anche quando non lo è: è una distinzione che costa parecchio a chi non la fa.

Le raccomandazioni dell’ACN in quell’occasione erano quattro: aggiornare subito alle versioni corrette; attivare i firewall applicativi in modalità di blocco, ricordando però che non sostituiscono l’aggiornamento; valutare di mettere offline i servizi che non si possono aggiornare; controllare i log alla ricerca di accessi anomali. Nessuna di queste quattro cose si fa da sola.

Il collo di bottiglia non è tecnico, è organizzativo

Qui sta il punto che mi interessa di più. La correzione per PHP esisteva il 21 ottobre. Era pubblica, gratuita, documentata. Quattro giorni dopo, in Italia, otto server su dieci con versione identificabile erano ancora scoperti. Non perché mancasse la tecnologia. Perché mancava qualcuno il cui compito fosse accorgersene e agire.

Nella maggior parte delle PMI italiane il sito non ha un responsabile. Ha avuto un realizzatore, qualche anno fa. Magari un’agenzia con cui il rapporto si è esaurito alla consegna, magari un hosting condiviso dove si dà per scontato che “ci pensa il provider”, cosa che per l’aggiornamento di PHP alla versione maggiore spesso non è vera: richiede una scelta esplicita di chi gestisce lo spazio, e un salto di versione può rompere plugin e temi obsoleti. Quindi nessuno lo fa, per paura di spaccare il sito.

È esattamente il meccanismo del debito tecnico: il rinvio è gratis oggi e costosissimo il giorno in cui presenta il conto. Solo che ora, con strumenti che accorciano i tempi di sfruttamento di una falla, l’intervallo tra il rinvio e il conto si sta riducendo. È lo stesso ragionamento che vale per le misure che proteggono davvero un sito WordPress: non si buca per via di tecnologie insicure in sé, si buca per plugin non aggiornati, componenti abbandonati e server lasciati a sé stessi.

Cosa significa davvero per un’azienda che vende online

Un attaccante che esegue codice sul tuo server non “ti rovina il sito”. Fa cose più scomode da raccontare.

• Accede ai dati dei clienti. Anagrafiche, ordini, indirizzi, in certi casi storici di pagamento. Dal punto di vista del GDPR è una violazione di dati personali, con obblighi di notifica al Garante entro tempi stretti e possibile comunicazione agli interessati.
• Usa il tuo dominio per altro. Pagine di phishing ospitate silenziosamente sul tuo spazio, invio di spam dal tuo server. Il risultato è il dominio in blacklist e le email aziendali che smettono di arrivare ai clienti.
• Inietta contenuto invisibile a te. Reindirizzamenti attivi solo per il traffico proveniente da Google, spam SEO in pagine che non apri mai. Te ne accorgi quando il posizionamento crolla.
• Blocca tutto e chiede un riscatto. Scenario meno frequente sui siti vetrina, molto concreto su gestionali e piattaforme di ordini.
• Resta dentro e aspetta. La compromissione più pericolosa è quella che non si manifesta. Senza controllo dei log, può durare mesi.

Per un’azienda che fa una parte significativa del fatturato online, l’esposizione non riguarda il sito. Riguarda il business. È la stessa ragione per cui valutare lo stato di salute di un sito aziendale non può limitarsi a un test di velocità e a uno sguardo alla grafica.

Aggiornare non è un’operazione da fare “quando capita”

C’è una paura legittima dietro il rinvio: aggiornare PHP o il core di un CMS può rompere qualcosa. Un plugin abbandonato, un tema modificato a mano anni fa, un’integrazione custom con il gestionale. È un rischio vero, e chi lo sottovaluta fa danni tanto quanto chi non aggiorna mai.

La risposta non è evitare l’aggiornamento: è farlo in un ambiente di prova, verificarlo, e poi portarlo in produzione con un backup fresco e una strada per tornare indietro. È lo stesso principio di cautela che vale per una migrazione WordPress fatta senza perdere posizionamento: la sequenza corretta conta più della velocità.

Un corollario poco simpatico ma necessario: se un sito non può essere aggiornato perché dipende da componenti che non esistono più, quel sito non ha un problema di manutenzione. Ha un problema di fine vita, e andrebbe pianificata una ricostruzione prima che lo decida qualcun altro al posto tuo.

Lo stesso strumento serve a chi difende e a chi attacca

Un sistema capace di leggere migliaia di righe di codice e individuare un use-after-free (un errore in cui il programma continua a usare una porzione di memoria già liberata, e che in certe condizioni permette di far eseguire codice arbitrario) non ha un’etica. Fa quello che gli si chiede. Se glielo chiede il team di sicurezza di un progetto open source, produce una segnalazione responsabile. Se glielo chiede qualcun altro, produce un punto di ingresso.

L’8 ottobre 2026 Anthropic ha lanciato quella che chiama Cyber Mission, e nel documento di presentazione mette per iscritto una cosa che va letta con attenzione: i modelli di frontiera possono essere usati in modo improprio per sfruttare vulnerabilità e condurre operazioni cyber. Il costo di sfruttare una falla è calato. Verificarla, divulgarla e correggerla, invece, resta un processo lento e dipendente dalle persone. Nel loro programma di ricerca Project Glasswing, scrivono, tra la scoperta e la correzione sono spesso passati mesi.

La stessa azienda dichiara di ritenere che nel giro di un paio d’anni l’intelligenza artificiale finirà per favorire chi difende, perché la difesa può industrializzare l’analisi del codice su scala molto più ampia di quanto possa fare un attaccante su un singolo bersaglio. Ma aggiunge che nel breve periodo potrebbe non andare così. Nel frattempo hanno rilasciato OSS Scanner, scansioni gratuite per i progetti open source, proprio per provare a spostare l’ago dalla parte giusta.

Tradotto per chi ha un’azienda: la finestra tra “si scopre una falla” e “quella falla viene usata contro di te” si sta accorciando. La finestra tra “esce la correzione” e “qualcuno la installa sul tuo server” no. Quella dipende ancora da una persona che se ne accorge e interviene.

Domande frequenti

Il mio sito è piccolo e non interessa a nessuno, sono davvero a rischio?

Gli attacchi che sfruttano vulnerabilità come quelle PHP di ottobre 2026 non selezionano i bersagli per importanza. Funzionano con scansioni automatiche che cercano in rete qualunque server con una certa versione esposta. Non c’è un essere umano che decide se vali la pena: c’è uno script che prova. Essere piccoli non protegge, semmai aumenta la probabilità che nessuno si accorga della compromissione.

L’hosting non pensa già lui agli aggiornamenti?

Dipende dal contratto, e la distinzione conta. Molti provider aggiornano il sistema operativo e applicano patch minori a PHP, ma il passaggio a una versione maggiore resta quasi sempre una scelta che devi fare tu dal pannello, perché può rompere il sito. E nessun hosting aggiorna per te il CMS, i plugin o il tema. Chiedi per iscritto cosa è incluso e cosa no.

Un firewall applicativo mi mette al sicuro mentre aspetto di aggiornare?

Aiuta, ma non sostituisce la correzione. L’ACN lo ha scritto in modo esplicito nelle raccomandazioni del 25 ottobre 2026: i firewall applicativi vanno attivati in modalità di blocco, però restano una misura di contenimento temporanea. Filtrano i tentativi noti, non la variante che qualcuno scriverà domani. Vanno usati per guadagnare giorni, non mesi.

Quanto spesso andrebbero fatti gli aggiornamenti di sicurezza?

Le patch critiche, quelle per falle sfruttabili da remoto senza autenticazione, vanno applicate nel giro di giorni, non di trimestri. Per tutto il resto, un ciclo mensile di verifica e aggiornamento su ambiente di prova è un ritmo ragionevole per una PMI. La cosa importante non è la frequenza perfetta: è che esista una frequenza e qualcuno che la rispetta.

Come faccio a sapere se il mio sito è già stato compromesso?

I segnali tipici sono traffico organico che crolla all’improvviso, avvisi di Google Search Console su contenuti sospetti, email aziendali che finiscono nello spam, file modificati in date che non corrispondono a nessun intervento, picchi di carico sul server senza spiegazione. Nessuno di questi è una prova da solo. Servono un controllo dei log e una verifica dell’integrità dei file fatta da chi sa dove guardare.

Se l’AI trova le falle, non le correggerà anche da sola?

In parte già succede: la vulnerabilità Node.js di ottobre 2026 è stata segnalata da uno strumento automatico. Ma segnalare e correggere sono passaggi diversi, e applicare la correzione sul tuo server lo è ancora di più. Anthropic stessa, presentando la Cyber Mission, ha scritto che la verifica, la divulgazione e la correzione restano processi lenti e dipendenti dalle persone. Quella parte, per ora, resta tua.

Una responsabilità che non si delega al caso

Quello che è successo negli ultimi mesi non dice che l’intelligenza artificiale abbia reso internet più pericoloso. Dice che ha reso più corto il tempo a disposizione, e il tempo era l’unica cosa che compensava una gestione approssimativa. Finché tra la pubblicazione di una falla e il primo tentativo di sfruttamento passavano settimane, rinviare l’aggiornamento al prossimo intervento aveva un costo basso. Adesso quel margine si sta assottigliando, mentre dall’altra parte la velocità di reazione dipende ancora da una persona che apre un pannello e decide di agire.

La cosa utile da fare oggi non è riorganizzare la sicurezza informatica dell’azienda. È più banale: scrivere a chi gestisce il tuo sito, chiedere su quale versione di PHP gira, chi applica le patch e quando è stato testato l’ultimo ripristino di backup. Tre risposte scritte. Se arrivano precise, hai un presidio. Se arrivano vaghe, hai appena scoperto una cosa che valeva la pena sapere prima che te la scoprisse qualcun altro.