Il 21 settembre 2026 il Dutch Institute for Vulnerability Disclosure (DIVD), organizzazione olandese senza scopo di lucro che segnala vulnerabilità ai proprietari dei sistemi esposti, è stato violato. Il 24 settembre l'istituto ha dichiarato che l'attacco sembrava condotto da un agente AI autonomo; il 30 settembre e il 1° ottobre sono emersi i dettagli sulle due falle zero-day di Zammad, il sistema di ticketing open source usato per l'assistenza clienti, sfruttate nell'attacco.

Cosa è successo

Secondo le ricostruzioni di Help Net Security, SecurityWeek e The Register, gli aggressori hanno sfruttato due vulnerabilità non ancora note in Zammad. La prima, CVE-2026-102489, consente a un utente non autenticato di eseguire codice da remoto e di sottrarre sessioni utente. La seconda, CVE-2026-102490, permette l'escalation locale dei privilegi fino a root. Concatenate, le due falle hanno permesso di dirottare sessioni, eseguire codice e passare dall'utente del servizio Zammad a root "in pochi secondi". SecurityWeek e The Register riportano per le falle un punteggio CVSS di 9,4.

Il DIVD ha scoperto l'intrusione il 22 settembre e ha bloccato l'accesso ai sistemi del data center; il 24 settembre ha segnalato le vulnerabilità al produttore e informato le autorità olandesi. Dei dati sottratti si sa poco: The Register riferisce il furto degli indirizzi e-mail dei ricercatori volontari dell'istituto, con possibili altri dati di contatto. Il DIVD afferma che la segmentazione di rete ha limitato i danni.

Cosa le fonti non dicono con precisione. Sulle versioni interessate i resoconti divergono: Help Net Security indica la CVE-2026-102489 come presente nelle versioni 6.3.0-6.5.4 e non sfruttabile nelle 7.0.0-7.1.3, mentre The Register e SecurityWeek riferiscono che anche le 7.0.0-7.1.3 contengono la falla pur essendo, per condizioni dell'ambiente, non sfruttabili. Sulla CVE-2026-102490 una fonte indica che interessi tutte le versioni e che al momento non esista una patch. Alla data di redazione non abbiamo trovato un avviso del produttore consultabile che chiarisca questi punti: chi usa Zammad deve quindi fare riferimento direttamente agli avvisi ufficiali del progetto.

Perché l'ipotesi dell'agente AI conta

Il DIVD sostiene che si trattasse di un attacco condotto da un agente AI sulla base del modus operandi: operazioni rapidissime, "rumorose e molto disordinate", uno script con commenti autoesplicativi tipici di un modello linguistico e decisioni prese dopo ogni azione senza intervento umano. Si tratta di una valutazione dell'istituto, non di una prova indipendente: non sono stati resi pubblici gli artefatti che permetterebbero a terzi di verificarla, e va trattata come tale.

Anche con questa cautela, l'implicazione pratica è chiara. Se un agente può concatenare due falle e arrivare a root in pochi secondi, la finestra tra la scoperta di una vulnerabilità e il compromesso completo si accorcia, e i tempi di reazione basati su "patch entro il prossimo ciclo" perdono senso. A ciò si aggiunge il dato citato da Google Threat Intelligence, riportato da Help Net Security: gli attaccanti sfrutterebbero le vulnerabilità scoperte con l'AI entro circa quattro giorni dalla divulgazione.

Cosa significa per le aziende italiane

I sistemi di ticketing e di help desk sono un bersaglio più interessante di quanto sembri. Contengono conversazioni con i clienti, allegati, indirizzi e-mail, a volte credenziali e dati personali scambiati "per comodità", e spesso sono esposti su Internet perché i clienti devono raggiungerli. Zammad è diffuso nelle PMI, negli enti locali e nei fornitori di servizi gestiti proprio perché è gratuito e installabile in autonomia: ma chi lo installa in autonomia ne è anche responsabile dell'aggiornamento.

Per i soggetti NIS2 questa è una questione di gestione delle vulnerabilità e di sicurezza della catena di approvvigionamento: il sistema di ticketing del fornitore che gestisce il vostro supporto è un punto d'accesso verso di voi. Per tutti, dal punto di vista GDPR, un accesso non autorizzato a un sistema che contiene dati di clienti va valutato come potenziale violazione dei dati personali; se i dati sono stati letti o copiati, la notifica al Garante entro 72 ore dalla scoperta è l'ipotesi di partenza, salvo valutazione documentata di rischio improbabile. Il fatto che la segmentazione abbia limitato il danno al DIVD è un buon esempio di misura che riduce davvero l'impatto: la stessa architettura, in un'azienda dove il ticketing è sulla stessa rete dei server interni, avrebbe esito diverso.

C'è infine un punto di realismo: due zero-day su un prodotto open source con una piccola comunità di manutenzione significano che non esiste, per ora, il comfort di una patch disponibile per tutte le configurazioni. In questi casi la mitigazione sta nell'architettura e nel monitoraggio, non nell'aggiornamento.

Cosa fare subito

  • Verificare se usate Zammad, anche in istanze dimenticate o installate da un fornitore, e identificare la versione in uso.
  • Seguire le indicazioni del DIVD e del progetto: aggiornare alla versione 7 oppure, in assenza di certezze sull'esposizione, mettere il sistema offline o raggiungibile solo da VPN/IP autorizzati finché il produttore non chiarisce lo stato delle patch.
  • Preservare i log applicativi e di rete prima di aggiornare o spegnere: servono a ricostruire un eventuale compromesso. Il DIVD ha messo a disposizione uno script di rilevamento per valutare un'eventuale compromissione.
  • Cercare segnali di compromissione: sessioni anomale, account creati di recente, processi e cron inattesi, connessioni in uscita dal server di ticketing, accessi verso altri servizi interni.
  • Isolare il sistema in un segmento di rete dedicato, senza accesso diretto a server interni, database di produzione e directory, e con credenziali di servizio a privilegi minimi.
  • Ruotare credenziali, token API e chiavi presenti nel sistema o accessibili da esso, e invalidare le sessioni attive.
  • Valutare l'impatto GDPR con il DPO se emergono accessi sospetti; documentare la decisione sulla notifica.
  • Accorciare i tempi di patching per i sistemi esposti: per le falle critiche con exploit concatenabile, ore o pochi giorni, non settimane.

Il punto

La parte verificata della vicenda è già sufficiente: due falle critiche in un prodotto molto diffuso, sfruttate prima che esistesse un rimedio completo. La parte ancora da verificare, cioè che l'autore sia davvero un agente AI autonomo, va seguita senza trasformarla in allarmismo, ma conferma una direzione: la velocità dell'attaccante sta aumentando, e l'unica risposta credibile è ridurre l'esposizione e il tempo di reazione.