Immaginate di dover entrare con lo SPID per pagare una multa e trovare il servizio spento «per precauzione». È successo la settimana scorsa agli olandesi con DigiD, la loro identità digitale, e a diversi portali pubblici in Finlandia e nelle prefetture francesi. Nessuno li aveva violati. Li hanno staccati i loro stessi gestori, perché non sapevano se sarebbero arrivati prima loro o i criminali.
Facciamo un passo indietro. Il 20 ottobre circolano in rete i dettagli di due falle in PHP, il linguaggio con cui gira una buona fetta dei siti del mondo (WordPress compreso). Le hanno battezzate PHP2Shell, permettono di prendere il controllo del server senza credenziali e valgono 9,2 su 10 nella scala di gravità. Il 21 ottobre esce la patch. Peccato che Patchstack, società specializzata nella sicurezza di WordPress, registri i primi attacchi già alle 7:34 di quella stessa mattina (ora di Greenwich), prima ancora che l'aggiornamento fosse disponibile. Il 26 ottobre l'agenzia americana CISA la inserisce nel catalogo delle vulnerabilità sfruttate e dà alle amministrazioni federali tre giorni per rimediare.
E da noi? Il 25 ottobre l'Agenzia per la Cybersicurezza Nazionale ha diramato un'allerta. In Italia ci sono 741.523 servizi PHP raggiungibili da Internet e 285.149 girano su versioni potenzialmente vulnerabili. Il CERT-AgID ha contato 650 indirizzi della pubblica amministrazione a rischio (per fortuna nessuno risulta compromesso). L'ACN segnala anche una seconda falla, ancora senza patch, per la quale l'unico rimedio è cambiare a mano un parametro di configurazione.
Ed ecco il punto su cui mi trovo spesso in disaccordo con chi dice «basta aggiornare». Aggiornare è indispensabile, ma da solo non basta più. Il rapporto M-Trends 2026 di Mandiant stima che in media le falle vengano sfruttate sette giorni prima che esca la correzione. VulnCheck, che tiene il conto delle vulnerabilità usate negli attacchi reali, dice che nel primo semestre 2026 quasi una su quattro (il 23,4%) è stata sfruttata entro il giorno stesso in cui è stata resa pubblica. Chi applica le patch una volta al mese, il secondo martedì come da tradizione Microsoft, arriva quasi sempre tardi.
E poi c'è un'altra questione. Siete sicuri che nella vostra azienda gli aggiornamenti vengano davvero installati? A me è capitato con un sito WordPress. Gli aggiornamenti automatici erano attivi, almeno sulla carta, ma da tempo non funzionavano più e nessuno se n'era accorto. La falla è stata sfruttata proprio lì.
Nella stessa settimana è uscita un'altra notizia che si è letta poco in Italia. Un ricercatore norvegese, Snorre Fagerland della società NorForge, insieme all'agenzia Reuters, ha ricostruito una campagna condotta con Cairn, uno strumento open source ad agenti di intelligenza artificiale nato per i penetration test autorizzati. Un attaccante di lingua cinese lo ha puntato contro oltre 1.200 siti e ha violato più di cento aziende, fra cui nomi come John Deere e Cummins. Ha speso circa 5.000 dollari di «token», cioè una cinquantina di dollari per ogni intrusione riuscita. Gli agenti cercavano le falle, le concatenavano e proseguivano da soli. Il tempo tra la pubblicazione di una vulnerabilità e il suo sfruttamento di massa, che già era breve, con questi strumenti si accorcia ancora (e i costi crollano).
Allora cosa possiamo fare? La prima risposta è ridurre quello che si può attaccare. Si chiama hardening, cioè la messa in sicurezza della configurazione, e per farlo esistono guide pubbliche e gratuite come i CIS Benchmark del Center for Internet Security, con istruzioni puntuali per sistemi operativi, server web, database e apparati di rete. Se sul vostro server c'è un servizio che nessuno usa, spegnetelo, perché un servizio disattivato non ha bisogno di patch. Una pagina di amministrazione che non si vede da Internet non la trova nemmeno un agente IA. Per come la vedo io, è la vecchia igiene informatica, applicata con metodo.
«Ma noi abbiamo il fornitore IT, ci pensa lui.» Io rispondo sì e no. È giusto che l'attività la faccia chi ne ha le competenze, ma la supervisione resta nostra. La NIS2 lo dice in modo esplicito, la responsabilità della gestione del rischio è degli organi di amministrazione, e dal 31 ottobre l'ACN può verificare se le misure di base sono state adottate e se funzionano. Un fornitore, poi, può avere problemi suoi. Zeabur, una piattaforma cloud usata da migliaia di sviluppatori, a metà ottobre ha subito la seconda violazione in due mesi (321.810 account esposti, credenziali interne lasciate in chiaro e chiavi di amministrazione mai cambiate) e ha annunciato che chiuderà il servizio entro il 31 dicembre. Chi ci aveva messo dati e applicazioni ha due mesi per traslocare. Nello stesso giorno della patch di PHP, la libreria LiteLLM, usata per collegare le applicazioni ai modelli di IA, è stata distribuita per circa due ore in una versione «avvelenata» che rubava le credenziali.
Una curiosità, per chi segue questa rubrica da un po'. Kaspersky ha appena descritto una nuova campagna del gruppo nordcoreano Lazarus contro aziende sudcoreane, e il malware usato cifra le sue comunicazioni con ML-KEM-1024, cioè con la crittografia post-quantistica di cui parlo da mesi. I criminali, almeno su questo, sono già migrati.
Lunedì mattina, quindi, fate al vostro responsabile IT, interno o esterno che sia, due domande. Come vengono gestite le patch, chi le approva, in quanto tempo vengono installate quelle critiche e chi lo fa se escono di venerdì sera? E quali punti di controllo abbiamo per sapere, in modo indipendente, se i nostri sistemi sono ancora vulnerabili (una scansione periodica, un inventario aggiornato, un confronto con i CIS Benchmark)? Se la risposta alla seconda domanda è «ci fidiamo», forse è il caso di cominciare da lì.