Zammad: zero-day in catena contro il DIVD, attacco con agenti IA

Il Dutch Institute for Vulnerability Disclosure (DIVD), l’organizzazione olandese di volontari che segnala in modo responsabile le vulnerabilità trovate nei sistemi esposti, ha reso pubblico di essere stato violato a sua volta. Gli attaccanti sono entrati dal suo helpdesk Zammad con due vulnerabilità allora sconosciute, la CVE-2026-102489 e la CVE-2026-102490, e secondo il DIVD l’operazione è stata condotta da agenti di intelligenza artificiale.

Della prima vulnerabilità abbiamo già scritto in un articolo dedicato. Questo articolo riguarda l’incidente, la catena di attacco e la seconda CVE, sulla base del rapporto e dei post del DIVD ripresi da The Register e Infosecurity Magazine.

Cosa è successo

• Cronologia: secondo la ricostruzione del DIVD riportata da The Register, l’intrusione è avvenuta il 21 settembre ed è stata scoperta il giorno dopo. Il DIVD ha bloccato l’accesso a tutti i sistemi del suo data center e ha formato un team di risposta con Merlon Security. Il 24 settembre ha segnalato le vulnerabilità al produttore, ha avvisato l’autorità olandese per la protezione dei dati e il National Cyber Security Centre e si è confrontato con la polizia. Infosecurity Magazine colloca invece al 24 settembre il momento in cui è stata notata l’attività sospetta: le due testate divergono sulla data della scoperta.
• Dati sottratti: secondo entrambe le testate, gli attaccanti hanno portato via dati dei volontari, tra cui gli indirizzi email DIVD e forse altri recapiti. Il DIVD sta ancora verificando quali dati di quali volontari siano coinvolti.
• Contenimento: secondo Infosecurity Magazine, il DIVD ha scritto che dal server Zammad gli attaccanti hanno raggiunto altri servizi e letto ed esfiltrato dati, ma che la segmentazione della rete e l’intervento del team hanno impedito di andare più in profondità.

La catena di attacco

Usate insieme, le due vulnerabilità hanno permesso di dirottare sessioni, eseguire codice a distanza ed elevare i privilegi dall’utente zammad a root: «in pochi secondi», scrive il DIVD, proprio per la parte automatizzata dell’attacco.

• CVE-2026-102489: secondo The Register, permette a un attaccante non autenticato di far trapelare le sessioni degli utenti e di eseguire codice a distanza come utente locale zammad. Versioni sfruttabili: dalla 6.3.0 alla 6.5.4. Il difetto c’è anche nel ramo 7 ma, secondo l’avviso del DIVD, non è sfruttabile per le condizioni dell’ambiente. The Register indica le versioni dalla 7.0.0 alla 7.1.3, mentre la descrizione NVD citata nel nostro articolo precedente si fermava alla 7.1.2.
• CVE-2026-102490: elevazione dei privilegi da utente locale a root. Secondo The Register sono vulnerabili tutte le versioni di Zammad.
• Punteggio: entrambe hanno un CVSS 4.0 di 9,4, calcolato nello scenario della catena dal DIVD, che è anche CNA e ha assegnato le due CVE.
• MITRE ATT&CK, mappatura indicativa ricavata dai fatti riportati: T1190 (Exploit Public-Facing Application), T1539 (Steal Web Session Cookie), T1068 (Exploitation for Privilege Escalation).

Le fonti non pubblicano indicatori di compromissione: il DIVD ha detto di non poter condividere altro per non ostacolare l’indagine.

Perché il DIVD parla di agenti IA

Il DIVD ha dichiarato di non aver mai visto un attacco simile, non per l’intrusione in sé ma per il modo di operare. Secondo The Register, lo ha descritto come «rumoroso e molto disordinato»: nei log si vedeva un agente che, dopo ogni azione, decideva da solo il passo successivo, a grande velocità e con una logica approssimativa.

L’indizio più concreto, riportato da entrambe le testate, sono i commenti negli script dell’attaccante: note in cui l’agente giustifica le proprie azioni, spiegando perché ciò che fa è lecito e «non è phishing». Un attaccante umano, osserva il DIVD, non perderebbe tempo a farlo. È una valutazione del DIVD basata sui log: le fonti non dicono quale modello o strumento sia stato usato né chi ci sia dietro.

Impatto per le aziende europee e italiane

Un helpdesk custodisce ticket, email e dati personali di clienti e dipendenti. Il caso del DIVD mostra due cose utili per chi difende: i tempi si accorciano, dalla sessione rubata a root in pochi secondi, e la segmentazione funziona, perché è ciò che ha limitato il danno. Tim Burke, di Quest Technology Management, intervistato da Infosecurity Magazine, aggiunge che con attacchi a velocità di macchina bisogna sapere in anticipo chi ha l’autorità per isolare sistemi e bloccare account.

C’è poi un rischio indiretto: con gli indirizzi dei volontari in mano agli attaccanti è più facile spacciarsi per il DIVD. Secondo The Register, l’organizzazione invita chi riceve email o richieste di contatto a suo nome che sembrano strane a verificarle scrivendo a communications@divd.nl.

Il DIVD ha notificato l’incidente all’autorità per la protezione dei dati e al centro nazionale per la sicurezza informatica. In Italia lo schema è lo stesso: notifica allo CSIRT Italia dell’ACN per i soggetti NIS2 e, se sono coinvolti dati personali, valutazione della notifica al Garante secondo il GDPR.

Cosa fare subito

1. Inventario: trova tutte le istanze Zammad con la loro versione; priorità a quelle raggiungibili da Internet e alle versioni dalla 6.3.0 alla 6.5.4.
2. Aggiorna o spegni: il DIVD raccomanda a tutti gli utenti di Zammad di passare alla versione 7 o di mettere il servizio offline il prima possibile. Le fonti non indicano una versione che corregga la CVE-2026-102490: verificala nell’avviso di Zammad.
3. Riduci l’esposizione e segmenta: finché non hai aggiornato, rendi l’helpdesk raggiungibile solo dalla rete interna o via VPN, e limita le connessioni dal server dell’helpdesk verso gli altri sistemi interni a quelle necessarie.
4. Cerca segni di compromissione sulle istanze esposte con versioni vulnerabili: comandi avviati dall’utente zammad, processi con privilegi di root inattesi, script nuovi nelle cartelle dell’applicazione e in quelle temporanee, sessioni anomale, connessioni dal server verso altri sistemi interni. Un’attività automatizzata si riconosce nei log dalla rapidità con cui le azioni si susseguono.
5. Dopo l’aggiornamento chiudi le sessioni attive. Se trovi tracce, sostituisci credenziali e token delle integrazioni e valuta di ricostruire il server: l’attaccante può aver ottenuto root.

Come aiuta ARXDOME

ARX Expose mostra quali servizi la tua azienda espone su Internet e quali prodotti vi sono riconosciuti, così un helpdesk raggiungibile da fuori emerge subito. ARX Shield elenca le vulnerabilità aperte sulle macchine monitorate, con quelle già sfruttate in evidenza, e permette di isolare dalla rete una macchina sospetta. ARX Sentry raccoglie log ed eventi dei server su cui è installato l’agent, comprese le esecuzioni sospette e le modifiche ai file nelle cartelle stabilite; con ARX Trace gli analisti ricostruiscono cosa è successo con raccolte e ricerche su più macchine.

Ultimo aggiornamento: 2 ottobre 2026