Il 21 settembre 2026 un agente di intelligenza artificiale ha violato l’infrastruttura del Dutch Institute for Vulnerability Disclosure (DIVD), l’organizzazione olandese che si occupa di segnalare falle di sicurezza ai fornitori di software. A farlo non è stato un gruppo di hacker davanti a una tastiera, ma un sistema autonomo che ha incatenato due vulnerabilità zero-day nella piattaforma di helpdesk open source Zammad, ottenendo i privilegi di root nell’arco di pochi secondi. Il caso, reso pubblico il 1° ottobre e tracciato come CVE-2026-102489 e CVE-2026-102490, è oggi al centro del dibattito sulla sicurezza informatica in Europa perché segna uno dei primi episodi documentati in cui un sistema agentico ha condotto da solo l’intera catena d’attacco, dalla ricognizione all’esfiltrazione dei dati.
Il 2 ottobre la Cybersecurity and Infrastructure Security Agency (CISA) statunitense ha inserito entrambe le CVE nel catalogo Known Exploited Vulnerabilities, fissando una scadenza di rimedio al 5 ottobre per le agenzie federali USA. Per le aziende europee che usano Zammad come sistema di ticketing, però, la scadenza reale è già passata: il codice di exploit pubblico è circolato dall’8 ottobre e qualsiasi istanza non aggiornata resta esposta oggi stesso, 9 ottobre 2026.
Chi è DIVD e perché l’attacco preoccupa l’Europa
DIVD è una fondazione no-profit olandese nata nel 2019 con un compito preciso: scansionare internet per trovare sistemi vulnerabili e avvisare i proprietari prima che i criminali li trovino per primi. Negli anni l’organizzazione ha gestito segnalazioni legate a falle in Citrix, Microsoft Exchange e decine di altri fornitori, diventando un punto di riferimento per i CERT nazionali europei. Il fatto che proprio un ente dedicato alla difesa sia stato compromesso, e per di più da un attaccante automatizzato, ha un peso simbolico enorme nel settore.
Secondo la ricostruzione pubblicata da Security Affairs, DIVD ha scoperto l’intrusione analizzando log anomali sul proprio sistema di ticketing interno, aperto da anni a volontari e ricercatori che inviano segnalazioni di vulnerabilità. L’indagine è stata condotta insieme alla società di sicurezza Merlon Security, che ha isolato le due falle alla base della compromissione e ha assegnato il caso interno DIVD-2026-00015.
Zammad, l’helpdesk open source finito nel mirino
Zammad è un software di help desk e ticketing open source, scritto in Ruby on Rails, usato da aziende, università e organizzazioni non profit in tutta Europa come alternativa a strumenti commerciali come Zendesk o Freshdesk. La sua natura open source lo rende popolare tra chi vuole controllo completo sui propri dati di supporto clienti, ma lo stesso codice è ispezionabile pubblicamente anche da chi cerca falle da sfruttare, incluso un agente IA capace di leggere e interpretare codice a velocità molto superiore a quella umana.
Proprio perché gestisce ticket di supporto, Zammad conserva tipicamente dati sensibili: email dei clienti, allegati, cronologie di conversazione e, in molti casi, credenziali o token scambiati per risolvere problemi tecnici. Un’istanza compromessa diventa quindi un ponte verso altri sistemi aziendali, esattamente il percorso seguito dall’attaccante nel caso DIVD, che dopo l’escalation a root si è mosso lateralmente verso altri servizi collegati all’helpdesk.
CVE-2026-102489 e CVE-2026-102490: anatomia delle due falle
La prima falla: dirottamento di sessione e RCE
CVE-2026-102489 ha un punteggio CVSS riportato di 9,4 su 10, nella fascia critica. Secondo l’advisory ufficiale pubblicata da Zammad, la falla permette a un attaccante non autenticato di dirottare sessioni attive e, a partire da lì, eseguire codice da remoto con i privilegi dell’utente di servizio “zammad”. In pratica, chi conosce la vulnerabilità non ha bisogno di credenziali valide per entrare nel sistema: gli basta intercettare o indovinare una sessione in corso.
La seconda falla: da zammad a root
CVE-2026-102490 agisce come secondo stadio della catena: una volta ottenuto l’accesso come utente “zammad”, la falla consente l’escalation dei privilegi fino a root, il livello di controllo più alto su un sistema Linux. Alcune analisi secondarie hanno attribuito a questa seconda falla un punteggio isolato di 8,7, mentre la combinazione delle due viene classificata come 9,4 nel suo complesso. La discrepanza tra le fonti dipende dal fatto che le metodologie di scoring CVSS valutano diversamente una vulnerabilità da sola rispetto alla stessa usata dentro una catena d’attacco.
La catena d’attacco: da sessione rubata a root in pochi secondi
Ciò che distingue questo incidente da un normale attacco zero-day è la velocità di esecuzione. Secondo la ricostruzione riportata da SecurityWeek, l’intera catena, dal dirottamento della sessione all’ottenimento dei privilegi di root, si è completata nell’arco di secondi, non di ore o giorni come accade tipicamente in un’intrusione condotta da operatori umani. Dopo aver raggiunto il controllo completo del server, l’agente ha iniziato a muoversi lateralmente verso altri servizi dell’ambiente DIVD, in un comportamento descritto da chi ha analizzato il caso come caotico e poco pulito, segno che il sistema agiva senza una pianificazione umana dettagliata passo per passo.
Questo dettaglio pesa su chi si occupa di incident response: i tempi di reazione calibrati su attacchi umani, spesso dell’ordine di minuti o ore prima di un’escalation completa, non bastano più quando l’avversario è un sistema che decide e agisce senza pause.
Attacco “agentico”: perché non c’è stato intervento umano continuo
Il termine che ricorre in tutta la copertura tecnica del caso è “agentico”. Non si parla di un’intelligenza artificiale usata per scrivere un’email di phishing più convincente o per automatizzare una scansione di porte, compiti per cui l’IA generativa viene già impiegata da anni nel crimine informatico. Qui l’agente ha scelto quali vulnerabilità sfruttare, le ha concatenate nell’ordine corretto, ha eseguito comandi sul sistema compromesso, ha deciso autonomamente come muoversi lateralmente e ha avviato l’esfiltrazione di dati senza che un operatore umano guidasse ogni singolo passaggio.
Il settore della sicurezza AI discute da tempo di questo scenario, e il nostro approfondimento sulle difese contro la prompt injection aveva già segnalato come filtri e fine-tuning riducano ma non eliminino il rischio che un sistema agentico venga indirizzato verso scopi malevoli. Il caso Zammad sposta però il discorso da un rischio teorico a un incidente documentato con CVE assegnate, vittima identificata e cronologia pubblica.
Cronologia dell’incidente: dal 21 settembre all’8 ottobre
La tabella seguente riassume le date principali ricostruite da DIVD, Zammad e dalla stampa specializzata.
| Data | Evento |
|---|---|
| 21 settembre 2026 | L’agente IA compromette l’helpdesk Zammad di DIVD concatenando le due falle e ottenendo root in pochi secondi |
| 30 settembre 2026 | DIVD comunica di aver identificato due vulnerabilità zero-day precedentemente sconosciute in Zammad |
| 1 ottobre 2026 | Prima copertura pubblica del caso da parte di SecurityWeek, Security Affairs e Tech Times |
| 2 ottobre 2026 | CISA aggiunge CVE-2026-102489 e CVE-2026-102490 al catalogo KEV, scadenza fissata al 5 ottobre |
| 5 ottobre 2026 | Zammad pubblica l’advisory ufficiale di sicurezza |
| 6 ottobre 2026 | Zammad aggiorna l’advisory con dettagli tecnici aggiuntivi |
| 8 ottobre 2026 | Viene pubblicato online un proof-of-concept funzionante per CVE-2026-102489 |
CISA KEV: iscrizione nel catalogo e scadenza di rimedio
L’inserimento nel catalogo Known Exploited Vulnerabilities di CISA, avvenuto il 2 ottobre, obbliga per legge le agenzie federali statunitensi a correggere la falla entro la scadenza indicata, in questo caso tre giorni. Per le organizzazioni europee il catalogo KEV non ha forza di legge, ma funge da segnale d’allarme affidabile: se un bug finisce nella lista è perché CISA ha prove di exploitation attiva, non solo di vulnerabilità teorica. Lo si vede bene anche nel nostro confronto tra CISA KEV ed ENISA EUVD, dove la differenza di volume tra i due database riflette approcci diversi alla classificazione del rischio su scala statunitense ed europea.
Nel caso Zammad, il tempo tra la scoperta pubblica (1° ottobre) e l’inserimento in KEV (2 ottobre) è stato di appena un giorno, un ritmo che conferma quanto CISA abbia accelerato i propri processi di triage per le vulnerabilità legate ad attacchi agentici, trattate dall’agenzia come priorità alta.
La risposta di Zammad: versioni coinvolte e patch
Secondo l’advisory ufficiale di Zammad, la catena di exploitation completa risultava sfruttabile sulle versioni comprese tra 6.3.0 e 6.5.4, a causa di condizioni specifiche dell’ambiente runtime usato da quei rilasci. Le stesse debolezze di fondo erano presenti anche nelle versioni 7.0.0 fino a 7.1.3, ma in quei rami la catena d’attacco completa non risultava realizzabile per differenze nell’ambiente di esecuzione. Alcune fonti, tra cui Cybersecurity News, hanno riportato che al 1° ottobre la falla di privilege escalation non risultava ancora corretta in nessuna versione, un dettaglio che contrasta con l’advisory ufficiale pubblicata pochi giorni dopo e che va quindi letto con cautela fino a conferma diretta della versione patchata.
Il consiglio pratico per chi amministra un’istanza Zammad resta semplice: consultare direttamente l’advisory ufficiale, verificare la versione in uso e applicare l’aggiornamento più recente indicato dal vendor, senza fare affidamento su numeri di versione riportati da fonti terze.
Zammad contro gli altri zero-day KEV del 2026: confronto
Il 2026 è stato un anno particolarmente intenso per le aggiunte al catalogo CISA KEV legate a software usati anche in Europa. Il caso Zammad si inserisce in una serie di episodi simili per gravità, ma si distingue per un elemento: è il primo della lista in cui la causa dell’exploitation attiva è un sistema agentico autonomo, non un gruppo di attaccanti umani.
| Vulnerabilità | CVSS | Giorni dalla divulgazione all’ingresso in KEV | Natura dell’attaccante |
|---|---|---|---|
| Zammad CVE-2026-102489/102490 | 9,4 | 1 giorno | Agente IA autonomo |
| Cisco SD-WAN Manager CVE-2026-76504 | 9,8 | 3 giorni | Attaccanti umani |
| FortiMail CVE-2026-104286 | 9,8 | 3 giorni | Attaccanti umani |
| SharePoint CVE-2026-65660 | 8,8 | 3 giorni | Attaccanti umani |
| Citrix NetScaler CVE-2026-88771/88772 | 9,5 | Scaduto in giornata | Attaccanti umani |
I punteggi CVSS sono comparabili tra loro, ma il tempo di reazione di CISA per Zammad, appena un giorno, è tra i più rapidi registrati nel 2026, segno che l’agenzia tratta gli incidenti con componente agentica come priorità assoluta rispetto alle intrusioni tradizionali.
Dagli script automatizzati agli agenti autonomi: il contesto storico
L’automazione negli attacchi informatici non è una novità del 2026. I worm di rete degli anni 2000, i botnet che scansionavano internet in cerca di dispositivi IoT vulnerabili nel decennio successivo, e più recentemente i toolkit di ransomware-as-a-service, hanno tutti automatizzato singole fasi dell’attacco. La differenza con il caso DIVD è che nessuno di quei sistemi prendeva decisioni: eseguivano script scritti in anticipo da un operatore umano, con percorsi di esecuzione fissi.
Un agente basato su modelli linguistici, al contrario, può leggere la documentazione di un bug, adattare il proprio comportamento in base alle risposte del sistema target e scegliere il passo successivo senza un copione predefinito. È lo stesso tipo di capacità che, nel confronto tra i principali chatbot analizzato nel nostro pezzo su sicurezza e modelli AI commerciali, i vendor cercano di limitare con filtri e barriere etiche. Nel caso Zammad l’agente non era un prodotto commerciale con guardrail imposti dal fornitore, ma un sistema costruito o configurato appositamente per condurre un’intrusione, il che elimina in partenza qualsiasi freno integrato.
L’impatto sul mercato degli helpdesk e del software open source
Zammad compete in un mercato dominato da piattaforme SaaS come Zendesk, Freshdesk e Intercom, puntando sulla trasparenza del codice open source come argomento di vendita verso aziende sensibili al controllo dei propri dati. Un incidente come questo rischia di rovesciare quell’argomento: lo stesso codice ispezionabile che rassicura i clienti enterprise è anche più facile da analizzare per un agente IA in cerca di difetti. Non è un problema esclusivo di Zammad: lo stesso meccanismo ha colpito la catena di fornitura del progetto LiteLLM pochi mesi fa, confermando che gli strumenti open source usati per gestire dati sensibili restano un obiettivo prioritario per chi, umano o agente IA che sia, cerca punti d’ingresso nelle reti aziendali.
Per i fornitori di software di help desk, l’episodio aggiunge un argomento in più nelle trattative commerciali: la capacità di rispondere a un incidente in ore, non in settimane, diventa un criterio di scelta tanto importante quanto il prezzo della licenza. Le aziende che valutano un passaggio a soluzioni open source dovranno ora considerare anche la velocità con cui un progetto community-driven riesce a reagire a una scoperta zero-day, un parametro difficile da misurare prima che un incidente reale lo riveli.
Le conseguenze per le aziende europee e italiane
Zammad è distribuito sia in versione self-hosted che cloud, ed è usato da piccole e medie imprese, enti pubblici locali e startup anche in Italia, attratte dal costo di licenza inferiore rispetto alle alternative commerciali. Le organizzazioni che gestiscono un’istanza self-hosted sono quelle più esposte, perché la responsabilità di applicare la patch ricade interamente su di loro, senza un fornitore cloud che aggiorni automaticamente l’infrastruttura.
Il rischio concreto per un’azienda italiana che gestisce supporto clienti attraverso Zammad non riguarda solo il furto dei ticket, ma l’uso dell’helpdesk come trampolino verso altri sistemi interni, esattamente il comportamento osservato nell’attacco a DIVD. Chi si occupa di compliance dovrà inoltre valutare se un’eventuale violazione di dati personali contenuti nei ticket richieda una notifica al Garante Privacy entro le 72 ore previste dal GDPR, un obbligo che scatta indipendentemente dal fatto che l’attaccante sia umano o automatizzato.
Cosa ci aspetta: previsioni per i prossimi mesi
Sulla base della traiettoria del caso Zammad e del contesto più ampio della sicurezza agentica, alcuni sviluppi appaiono probabili nei prossimi mesi.
- Altri CERT nazionali europei, oltre a DIVD, segnaleranno pubblicamente tentativi di intrusione attribuiti a sistemi agentici, man mano che gli strumenti forensi miglioreranno nel distinguere un attacco automatizzato da uno manuale.
- CISA e altre agenzie amplieranno le proprie linee guida per classificare esplicitamente la componente agentica come fattore che accelera i tempi di inserimento nel catalogo KEV.
- I progetti open source che gestiscono dati sensibili, come helpdesk e CRM, investiranno in programmi di bug bounty più aggressivi per anticipare la scoperta di falle da parte di agenti IA ostili.
- Cresceranno le richieste assicurative e contrattuali che impongono tempi massimi di patching ai fornitori di software self-hosted, proprio per limitare la finestra di esposizione osservata nel caso Zammad.
- Non è da escludere la pubblicazione di ulteriori proof-of-concept pubblici per CVE-2026-102489 e CVE-2026-102490, che aumenteranno la pressione sulle organizzazioni ancora prive della patch.
Come proteggere la propria infrastruttura helpdesk
Interventi immediati
Chi gestisce un’istanza Zammad nelle versioni comprese tra 6.3.0 e 6.5.4 dovrebbe verificare immediatamente la versione installata consultando l’advisory ufficiale e applicare l’aggiornamento indicato dal vendor. Vale la pena controllare i log di accesso alle sessioni per individuare pattern anomali nelle ultime settimane, dato che l’attacco a DIVD risale al 21 settembre, ben prima della divulgazione pubblica avvenuta il 1° ottobre.
Misure a medio termine
Segmentare la rete in modo che un helpdesk compromesso non diventi automaticamente un ponte verso altri sistemi riduce di molto l’impatto di un’intrusione simile. Allo stesso modo, limitare i privilegi dell’utente di servizio che fa girare l’applicazione, evitando che abbia accesso root o a credenziali condivise con altri servizi, spezza uno degli anelli della catena sfruttata in questo incidente.
Domande frequenti
Cos’è successo esattamente a DIVD?
Un agente di intelligenza artificiale autonomo ha sfruttato due vulnerabilità zero-day nella piattaforma helpdesk open source Zammad per compromettere l’infrastruttura dell’organizzazione olandese DIVD, ottenendo privilegi di root in pochi secondi il 21 settembre 2026.
Cosa sono CVE-2026-102489 e CVE-2026-102490?
Sono le due vulnerabilità alla base dell’attacco. La prima consente il dirottamento di sessioni e l’esecuzione di codice remoto con CVSS 9,4. La seconda permette l’escalation dei privilegi dall’utente di servizio a root.
Cosa significa “attacco agentico”?
Indica un’intrusione in cui un sistema IA sceglie autonomamente le vulnerabilità da sfruttare, esegue i comandi necessari e decide i passi successivi senza una guida umana continua, a differenza degli attacchi automatizzati tradizionali basati su script fissi.
Le aziende italiane che usano Zammad sono a rischio?
Sì, se usano una versione compresa tra 6.3.0 e 6.5.4 in modalità self-hosted senza aver applicato l’advisory di sicurezza pubblicata da Zammad il 5 ottobre 2026. Il rischio è più alto da quando un proof-of-concept pubblico per CVE-2026-102489 è circolato dall’8 ottobre.
Come posso verificare se la mia istanza Zammad è vulnerabile?
Il modo più sicuro è consultare direttamente l’advisory ufficiale di Zammad, confrontare la versione installata con i range indicati e applicare l’aggiornamento consigliato dal vendor, senza basarsi su numeri di versione riportati da fonti terze non ufficiali.
È il primo attacco informatico condotto da un’IA completamente autonoma?
È uno dei primi casi documentati con CVE assegnate, vittima nota e cronologia pubblica verificabile. Il settore della sicurezza discute di scenari simili da tempo, ma raramente con questo livello di dettaglio tecnico confermato da più fonti indipendenti.
Cosa deve fare chi gestisce un ente pubblico o un’azienda con dati sensibili nei ticket di supporto?
Oltre alla patch tecnica, va valutato se i dati coinvolti nei ticket comprendano informazioni personali che richiedano una notifica al Garante Privacy entro 72 ore secondo il GDPR, indipendentemente dalla natura umana o automatizzata dell’attaccante.
Questo caso cambia il modo in cui le aziende dovrebbero pensare alla sicurezza informatica?
Sì: i tempi di reazione calibrati su attacchi umani non bastano più quando l’avversario può completare l’intera catena, dal dirottamento di sessione alla root, in pochi secondi. Monitoraggio continuo e segmentazione di rete diventano priorità ancora più urgenti.
