Hacker AI: violati i cacciatori di falle

Lunedì 21 settembre, Paesi Bassi. Qualcuno entra nei server del DIVD.

Il DIVD, Dutch Institute for Vulnerability Disclosure, è un’organizzazione senza scopo di lucro fatta in gran parte di volontari. Il suo mestiere è cercare le falle nei programmi degli altri, segnalarle a chi li produce e avvisare chi li usa prima che arrivino i malintenzionati. Sono cacciatori di falle. Stavolta la falla l’hanno trovata in casa propria.

Il 24 settembre l’hanno scritto così: «Ci abbiamo messo quasi sette anni, ma adesso possiamo dirlo: siamo gli hacker che sono stati hackerati». E hanno aggiunto il dettaglio che trasforma un incidente in una notizia: secondo loro, a entrare è stato un agente di intelligenza artificiale. Un programma che decideva da solo la mossa successiva. E che, mentre lo faceva, lasciava lunghe spiegazioni delle sue scelte.

Cosa è successo

La cronologia l’ha pubblicata il DIVD stesso, giorno per giorno, nel fascicolo dell’incidente. Il titolo è già una dichiarazione: «When, not if…», quando, mai se. Nella sicurezza informatica lo si ripete da anni: la domanda è quando ti attaccheranno.

• 21 settembre: primo accesso dell’attaccante ai sistemi del DIVD.
• 22 settembre: il DIVD si accorge dell’attività sospetta e blocca l’accesso a tutti i sistemi del suo centro dati. Parte l’indagine, con la società di sicurezza Merlon Security.
• 24 settembre: primo annuncio pubblico, che parla già di un attacco condotto da un’AI. Il DIVD segnala l’incidente all’autorità olandese per la protezione dei dati e al Centro nazionale per la sicurezza informatica, e valuta le opzioni con la polizia. Lo stesso giorno avvisa Zammad della falla.
• 26 e 28 settembre: altri aggiornamenti sul modo di agire dell’AI e su quello che si sa.
• 30 settembre: il DIVD rende pubbliche le due falle di Zammad da cui è passato l’attacco.
• 1 ottobre: pubblica una pagina su quali dati sono stati colpiti e quali no, con lo stato dell’indagine.

Cosa è uscito, di preciso, lo stanno ancora ricostruendo. Una cosa la danno per certa: sono stati portati fuori gli indirizzi email del DIVD e forse i recapiti di alcuni volontari. Sul resto, dal sistema con cui gestiscono le segnalazioni alle conversazioni interne, l’indagine è aperta. Nel frattempo trattano tutto come violato, finché non riescono a dimostrare il contrario.

Restano aperte anche le due domande più grosse: chi c’è dietro, e perché. Secondo Help Net Security non si sa se l’agente inseguisse un obiettivo dentro un attacco più grande o se fosse una prova di capacità. E nessuna delle fonti dice quale AI abbia usato l’attaccante.

Anche chi controlla le serrature degli altri ha una porta di servizio.

La porta di servizio: Zammad

L’attaccante è entrato dal programma dell’assistenza.

Zammad è un programma open source, cioè con il codice pubblico, che serve a gestire le richieste dei clienti, le richieste di assistenza informatica e i ticket interni: ogni richiesta diventa una scheda, con la sua storia e chi se ne occupa. Si può installare sui propri server o usare come servizio già pronto. Secondo BleepingComputer, sul suo sito l’azienda dichiara più di 2.000 clienti e 55.000 utenti, fra cui De’Longhi, Amnesty International e Nextcloud. Il DIVD lo usava al suo interno.

Le falle erano due, ed erano «zero-day»: difetti che chi ha scritto il programma ancora non conosceva, e per cui al momento dell’attacco non esisteva una correzione. Il nome viene da lì. Il giorno in cui la falla viene usata, chi dovrebbe correggerla ha avuto zero giorni per farlo.

La prima ha la sigla CVE-2026-102489 (CVE è il catalogo internazionale delle falle note). Permette di rubare la sessione di un utente collegato e di far eseguire comandi al server da lontano. Secondo SecurityWeek funziona senza credenziali: all’attaccante basta raggiungere il programma, senza bisogno di una password valida. Riguarda le versioni di Zammad dalla 6.3.0 alla 6.5.4. Il difetto c’è anche nelle versioni dalla 7.0.0 alla 7.1.3, ma lì, scrive il DIVD, non si può sfruttare per come è configurato l’ambiente.

La seconda, CVE-2026-102490, fa il resto. Chi è dentro con l’utente del programma può prendersi i poteri di «root», l’amministratore assoluto del server, quello che può fare tutto. Questa falla c’è in tutte le versioni, dalla 1.5.0 all’ultima di prova, e al 1° ottobre, secondo TechTimes, una correzione non c’era ancora. Il DIVD scrive che Zammad ci sta lavorando. SecurityWeek dà a tutte e due un punteggio di gravità di 9,4 su 10.

Messe in fila, dice il DIVD, le due falle hanno permesso di rubare sessioni, eseguire codice da remoto e passare dall’utente di Zammad a root «in pochi secondi, per via della parte agentica di questo attacco». Da lì l’attaccante ha raggiunto altri servizi, ha letto dati e ne ha portati fuori una parte. Più a fondo l’hanno fermato la rete divisa in compartimenti e la squadra che risponde agli incidenti. «Una parte del danno, purtroppo, era già fatta», hanno scritto.

La porta più pericolosa è quella che usi tutti i giorni e a cui hai smesso di pensare.

Un hacker che decide da solo

Un agente AI è un programma a cui dai un obiettivo e che poi sceglie da solo i passi per arrivarci: fa una mossa, guarda cosa succede, decide la successiva. È lo stesso principio degli assistenti che lavorano da soli per conto di chi li usa, come i dots che OpenAI ha lanciato il 29 settembre. Messo in mano a chi attacca, diventa uno scassinatore instancabile, che passa da una serratura all’altra senza fermarsi a riflettere.

Il DIVD l’ha descritto così: «Vedevamo l’agente lavorare in automatico, perché dopo ogni azione decideva da solo il passo successivo, alla velocità della luce, con una logica e uno schema approssimativi». E ha aggiunto che l’agente ha fatto anche cose piuttosto stupide: per esempio ha mescolato un suo tentativo di intercettare le comunicazioni con tentativi di entrare provando poche password comuni su molti account.

Poi la frase più bella: «Ma quello che rende questo attacco piuttosto notevole è che l’agente spiega così tanto nei suoi commenti da renderci molto più facile ricostruirlo a ritroso».

Rileggi. Velocissimo e approssimativo. Instancabile e chiacchierone. L’attaccante ha lasciato il diario sulla scena del crimine.

Non è la prima volta che un’AI fa gran parte del lavoro di un attacco. A novembre 2025 Anthropic aveva raccontato una campagna di spionaggio che attribuisce, «con alta fiducia», a un gruppo sostenuto dallo Stato cinese: il gruppo aveva manipolato il suo strumento Claude Code per tentare di entrare in una trentina di organizzazioni nel mondo, riuscendoci in pochi casi. Secondo Anthropic l’AI aveva svolto fra l’80 e il 90% della campagna, con migliaia di richieste, spesso più d’una al secondo. E anche lì sbagliava: a volte si inventava credenziali o spacciava per segrete informazioni che erano pubbliche.

Il tratto comune è questo: la velocità di una macchina con la sbadataggine di un principiante. Per chi difende è una notizia buona e una cattiva insieme. La buona: un attaccante così lascia tracce. La cattiva, nella mia lettura: se è abbastanza veloce, gli basta essere mediocre.

Il 29 settembre, alla Casa Bianca, le grandi aziende dell’AI hanno firmato un patto che, fra le altre cose, chiede di sorvegliare che i modelli non entrino in sistemi informatici in modi non previsti. Il caso del DIVD mostra l’altro lato della stessa medaglia: un agente lo può lanciare anche chi quel patto non l’ha firmato. Lo stesso 30 settembre in cui il DIVD rendeva pubbliche le falle, Google ha presentato Gemini 4 Argon e l’ha dato prima di tutto a un gruppo selezionato di difensori informatici. La gara fra chi attacca e chi difende si corre sempre di più con gli stessi strumenti.

Chi attacca ha imparato a delegare. Chi difende, nella mia lettura, deve arrivare con le sue mosse già preparate.

Cosa cambia per chi ha un’azienda

Forse Zammad non l’hai mai sentito nominare. Ma la tua azienda ha quasi certamente qualche porta simile: il sito con i suoi componenti aggiuntivi (i plugin), il programma con cui rispondi ai clienti, il gestionale online, la posta, l’accesso da remoto per lavorare da casa. Programmi che stanno su internet giorno e notte, aggiornati quando qualcuno se ne ricorda.

La prima lezione riguarda il tempo. Secondo il DIVD, l’agente ha eseguito in pochi secondi i passaggi che lo hanno portato ai pieni poteri sul server, decidendo da solo ogni mossa. Quanto tempo sia servito per trovare le falle e preparare l’attacco, le fonti non lo dicono. La conseguenza pratica, per come la vedo io: gli aggiornamenti dei programmi esposti su internet vanno affidati a una persona con nome e cognome, che sa cosa fare il giorno in cui esce una correzione urgente. Per Zammad, oggi, la raccomandazione è passare alla versione 7 o toglierlo da internet il prima possibile.

La seconda lezione viene da quello che ha salvato il DIVD. L’attaccante è arrivato ai pieni poteri su un server, eppure è stato fermato prima di andare più a fondo: la rete era divisa in compartimenti e la squadra di risposta ha reagito. Come le paratie di una nave: se una stanza si allaga, le altre restano asciutte. In una piccola azienda può voler dire, per esempio, che il programma dell’assistenza clienti vive separato dalla contabilità, e che una password rubata apre una stanza sola.

La terza lezione è la più vicina al mio mestiere. Dopo un furto di dati, il pericolo cambia forma. Il DIVD lo scrive chiaro: con gli indirizzi email del DIVD e forse i recapiti dei volontari in giro, cresce il rischio di «social engineering», l’ingegneria sociale, cioè l’arte di manipolare le persone invece dei computer. Qualcuno può spacciarsi per un membro del DIVD per farsi aprire una porta. È l’argomento di autorità usato come grimaldello: un messaggio che sembra arrivare da qualcuno di cui ti fidi abbassa le difese prima ancora che tu lo legga per intero. Per questo, quando un nome che conosci ti chiede una cosa insolita, come una password, un pagamento o un clic di fretta, la verifica si fa per un’altra strada: una telefonata al numero che avevi già, invece di quello scritto nel messaggio.

Il primo attacco ruba i dati. Il secondo li usa per convincerti.

Come si racconta un attacco

E poi c’è il modo in cui il DIVD sta raccontando tutto questo. Che è, a modo suo, un piccolo manuale di comunicazione di crisi.

Hanno scelto la trasparenza piena, e l’hanno scritto: «Abbiamo scelto la trasparenza totale, il che significa che comunichiamo anche le cose che non sappiamo». Hanno pubblicato un elenco provvisorio dei dati da verificare e, accanto, lo stato dell’indagine: cosa è sicuramente uscito, cosa stanno ancora controllando. Precisano che l’elenco è incompleto e che un dato elencato è da controllare, senza essere per forza compromesso. E hanno ricordato che il regolamento europeo sulla privacy chiede di avvisare le persone i cui dati sono usciti «senza ingiustificato ritardo». Il loro commento: «Non dice “quando l’ufficio stampa si sente pronto”».

Poi la metafora, che vale da sola il prezzo della lettura. Troppo spesso, scrivono, notizie come questa escono con la «tattica del salame». Servire il salame intero farebbe venire a tutti il mal di pancia. Così lo si taglia a fette sottili, sperando che ognuna faccia meno male, rovini meno la reputazione e vada giù più facilmente.

Perché, secondo me, è la scelta giusta? Perché in una crisi la fiducia si può perdere due volte: quando succede il fatto, e quando scopri che te l’hanno raccontato a rate. Il fatto, spesso, non lo scegli. Il modo di raccontarlo sì.

C’è anche un dettaglio più sottile. Dire «questo ancora non lo sappiamo» sembra un’ammissione di debolezza. In realtà è la frase che rende credibili tutte le altre. Chi dichiara i propri buchi ti dà un motivo per credere che il resto sia pieno.

In Italia, se un attacco tocca dati personali, la regola ha una scadenza precisa. Il titolare del trattamento, cioè chi decide perché e come usare i dati, che sia un’impresa, un professionista o un’associazione, deve avvisare il Garante della privacy senza ingiustificato ritardo e, dove possibile, entro 72 ore da quando se ne accorge, a meno che sia improbabile un rischio per le persone. Oltre le 72 ore deve spiegare il perché del ritardo.

Settantadue ore passano in fretta, se il comunicato lo cominci a scrivere quel giorno.

Come portarlo nel tuo lavoro

Cinque cose da fare questa settimana, in ordine di urgenza.

1. Se tu o il tuo fornitore usate Zammad, chiedete oggi quale versione gira. Il DIVD raccomanda di passare alla versione 7 o di spegnerlo. Prima di aggiornare, riporta TechTimes, il Centro nazionale olandese per la sicurezza informatica consiglia di copiare i registri del programma e della rete: se in futuro si saprà di più sulla seconda falla, serviranno a capire se sei stato attaccato. Il DIVD ha pubblicato anche uno script, un piccolo programma, che cerca nei registri di Zammad le tracce note della prima falla: se non trova niente, da solo non basta a escludere altro. E ricorda che la falla che porta ai pieni poteri resta aperta finché Zammad non pubblica la correzione.
2. Fai l’elenco dei programmi che la tua azienda tiene aperti su internet: il sito e i suoi plugin, l’assistenza clienti, il gestionale online, la posta, l’accesso da remoto. Accanto a ognuno scrivi due cose: chi lo aggiorna e ogni quanto. Dove la risposta è «boh», hai trovato il tuo punto debole.
3. Chiedi a chi segue la tua parte informatica se la rete è divisa in compartimenti. La domanda da fare è semplice: se entrano dall’assistenza clienti, cosa trovano? La risposta che vuoi sentire è «solo l’assistenza clienti».
4. Prepara adesso il piano per il giorno brutto: chi decide, chi valuta se va avvisato il Garante e chi provvede alla notifica, senza ingiustificato ritardo e, dove possibile, entro 72 ore da quando vieni a sapere della violazione, chi scrive ai clienti e con quali parole. Scrivi anche come i tuoi clienti possono riconoscere i tuoi messaggi veri, per esempio da quali indirizzi scrivi e cosa chiedi solo di persona o al telefono. Così l’ingegneria sociale del giorno dopo trova la strada più stretta.
5. Se fai lavorare agenti AI per te, decidi prima cosa possono toccare e cosa deve sempre passare da te: è l’ultimo dei cinque livelli di delega, quello dell’autonomia. Gli assistenti imparano ad agire da soli, dagli agenti che lavorano giorno e notte alle skill di Gemini, istruzioni salvate che Gemini può avviare da solo quando riconosce la richiesta giusta. I casi del DIVD e di Anthropic mostrano che autonomia e velocità possono andare insieme agli errori: per questo i limiti e i controlli si decidono prima.

Il DIVD si è difeso con due cose: le paratie e la sincerità. Le paratie hanno fermato l’attaccante. La sincerità, nella mia lettura, può limitare il secondo danno, quello alla fiducia.

👉 Leggi anche: Gli agenti AI di OpenAI hanno sconfinato

👉 Leggi anche: Chrome: 2 falle critiche su 4 trovate con l’AI — l’altra faccia della stessa medaglia: un ricercatore di Anthropic con Claude segnala dodici falle di Chrome.

Domande frequenti

Cos’è un hacker AI?

È il modo più rapido per dire un attacco informatico condotto, in tutto o in parte, da un agente AI: un programma che riceve un obiettivo e decide da solo i passi per raggiungerlo. Dietro c’è comunque qualcuno che lo lancia. Nel caso del DIVD chi sia, e con quale AI, ancora non si sa.

Cos’è Zammad e chi lo usa?

È un programma open source per gestire le richieste dei clienti, l’assistenza informatica e i ticket interni, da installare sui propri server o da usare come servizio. Secondo quanto l’azienda dichiara sul suo sito, ripreso da BleepingComputer, ha più di 2.000 clienti e 55.000 utenti, fra cui De’Longhi, Amnesty International e Nextcloud.

Uso Zammad: cosa devo fare?

Passare alla versione 7 o spegnerlo, come raccomanda il DIVD. Prima dell’aggiornamento conviene conservare una copia dei registri del programma e della rete, come consiglia il Centro nazionale olandese per la sicurezza informatica secondo TechTimes. Lo script pubblicato dal DIVD cerca nei registri di Zammad le tracce note della prima falla; un controllo senza risultati non esclude altre compromissioni. La versione 7 blocca il primo anello dell’attacco; la falla che porta ai poteri di amministratore resta aperta finché Zammad non pubblica la correzione.

Cos’è una vulnerabilità zero-day?

È un difetto di un programma che chi l’ha scritto ancora non conosce, e per cui non esiste una correzione, quando qualcuno comincia a sfruttarlo. Il nome dice che chi deve correggerlo ha avuto zero giorni per farlo.

È il primo attacco informatico fatto da un’AI?

A novembre 2025 Anthropic aveva già documentato una campagna di spionaggio in cui l’AI svolgeva fra l’80 e il 90% del lavoro. Il DIVD dice di non aver mai visto un attacco come questo, per il modo in cui l’agente agiva. Se fosse parte di un attacco più grande o una prova di capacità, ancora non si sa.

Se la mia azienda subisce un attacco, entro quando devo avvisare il Garante?

Se sono coinvolti dati personali e la tua azienda è il titolare del trattamento, senza ingiustificato ritardo e, dove possibile, entro 72 ore da quando te ne accorgi, salvo che il rischio per le persone sia improbabile. Se avvisi più tardi, devi spiegare il motivo del ritardo. Ogni violazione va comunque documentata, per esempio in un registro.

Fonti

• DIVD, fascicolo dell’incidente DIVD-2026-00014 «When, not if…», aggiornato al 1° ottobre 2026
• DIVD, fascicolo DIVD-2026-00015 sulle falle di Zammad, aggiornato al 1° ottobre 2026
• DIVD, Overview of data investigation, 1° ottobre 2026
• DIVD, It was a matter of when, not if…, 24 settembre 2026
• BleepingComputer, DIVD says Zammad zero-days enabled AI-driven network breach, 30 settembre 2026
• SecurityWeek, Zammad Zero-Days Exploited in AI-Powered DIVD Hack, 1° ottobre 2026
• Help Net Security, AI agent used Zammad zero-days to breach Dutch vulnerability disclosure non-profit, 1° ottobre 2026
• Security Affairs, AI Agent Chains Zammad Zero-Days To Take Over DIVD Systems in Seconds, 1° ottobre 2026
• TechTimes, AI Agent Hacked Cybersecurity Nonprofit DIVD via Zammad Zero-Days; Root Flaw Unpatched, 1° ottobre 2026
• Anthropic, Disrupting the first reported AI-orchestrated cyber espionage campaign, 13 novembre 2025
• Garante per la protezione dei dati personali, Violazioni di dati personali (data breach)