Due zero-day di Zammad permettono a un intruso guidato dall’IA di ottenere privilegi root sui sistemi DIVD

DIVD riconduce la violazione della propria rete a una catena di exploit basata su due vulnerabilità

Il Dutch Institute for Vulnerability Disclosure ha ricondotto una recente violazione della propria rete a due vulnerabilità inedite di Zammad, una piattaforma open source per la gestione dell’helpdesk e delle richieste di assistenza.

Secondo quanto riportato sull’indagine di DIVD, l’attaccante ha combinato CVE-2026-102489 e CVE-2026-102490 per compromettere l’ambiente Zammad di DIVD. La catena avrebbe consentito di dirottare sessioni, eseguire codice da remoto e aumentare i privilegi dall’account di servizio di Zammad fino a root.

L’intruso ha poi raggiunto altri servizi, consultato informazioni sui sistemi DIVD ed esfiltrato dati. La segmentazione della rete e le misure adottate dall’organizzazione in risposta all’incidente hanno impedito che l’attacco si propagasse ulteriormente, ha dichiarato DIVD.

Al momento della pubblicazione del resoconto citato, l’indagine era ancora in corso. DIVD aveva annunciato un nuovo aggiornamento per «domani», senza specificare l’orario esatto.

Da una sessione sottratta al controllo root

Le due vulnerabilità sembrano aver avuto ruoli complementari, anziché produrre effetti separati. DIVD ha descritto una sequenza d’attacco iniziata con il controllo di una sessione autenticata e proseguita con l’esecuzione di codice arbitrario.

Secondo quanto riferito, l’attaccante è poi riuscito a superare i limiti dell’account Zammad e a ottenere privilegi root. Su un normale sistema Linux, l’accesso root consente il massimo livello di controllo: per questo l’escalation finale è particolarmente grave, anche in assenza di un punteggio CVSS pubblicato.

La catena d’attacco descritta può essere riassunta così:

1. Lo sfruttamento delle vulnerabilità di Zammad ha consentito il dirottamento di una sessione.
2. Il contesto compromesso è stato usato per eseguire codice da remoto.
3. L’attaccante è passato dall’account Zammad ai privilegi root.
4. L’intrusione si è estesa ad altri servizi raggiungibili dall’ambiente compromesso.
5. I dati sono stati consultati ed esfiltrati prima che le misure di contenimento limitassero ulteriori spostamenti.

Il resoconto disponibile non chiarisce quale vulnerabilità abbia consentito ciascuna fase, in che modo sia stata sottratta la sessione né quale meccanismo abbia reso possibile l’esecuzione remota. Non include inoltre codice proof of concept, schemi delle richieste o altri dettagli tecnici sugli exploit.

Le informazioni pubbliche, da sole, non bastano quindi a creare rilevamenti specifici per queste vulnerabilità. Ciò non ridimensiona l’impatto descritto: DIVD afferma che le falle sono state sfruttate con successo contro la propria infrastruttura.

Secondo DIVD, l’intrusione è stata orchestrata da un agente di IA

Un aspetto distintivo dell’incidente è la valutazione di DIVD secondo cui l’operazione sarebbe stata condotta da un agente di IA in grado di scegliere autonomamente le azioni successive.

L’organizzazione ha dichiarato che, nel giro di pochi secondi, l’agente è passato dallo sfruttamento delle vulnerabilità all’escalation dei privilegi, all’accesso ai servizi e al furto di dati, senza indicazioni esterne durante questa sequenza. DIVD ha inoltre riferito che il sistema ha lasciato traccia delle motivazioni alla base delle proprie decisioni, aiutando gli investigatori a ricostruire l’attacco.

Questa valutazione va circoscritta a quanto emerso dall’indagine di DIVD. Il resoconto attribuisce all’agente la capacità di prendere decisioni autonome in questo incidente, ma non chiarisce come l’attaccante abbia sviluppato il sistema, quale modello abbia utilizzato o quanto lavoro di preparazione sia stato svolto prima dell’avvio delle attività automatizzate.

La velocità ha implicazioni concrete sul piano operativo. Una catena automatizzata che valuta gli accessi e seleziona subito le azioni successive può concentrare più fasi dell’intrusione in una finestra troppo breve per un intervento manuale. Le difese devono quindi essere in grado di bloccare o contenere automaticamente le attività, senza affidarsi esclusivamente alla capacità di un analista di notare ogni passaggio e intervenire.

In questo caso, la segmentazione ha contribuito a limitare i danni. L’attaccante ha raggiunto altri servizi, ma, secondo DIVD, i controlli hanno impedito che si spostasse ulteriormente nella rete.

Non è ancora chiaro quali versioni di Zammad siano vulnerabili

Zammad è disponibile sia per l’installazione autonoma sia in hosting. La piattaforma supporta la gestione delle richieste dei clienti, dei flussi di assistenza IT e dei ticket interni: può quindi rappresentare un obiettivo interessante, perché i sistemi di ticketing possono contenere comunicazioni sensibili ed essere collegati ad altri servizi aziendali.

Il fornitore dichiara di avere oltre 2.000 clienti e 55.000 utenti. Tra le organizzazioni indicate nel resoconto come utenti di Zammad figurano De’Longhi, Amnesty International e NextCloud. La loro citazione in questo contesto non implica che i loro sistemi siano stati attaccati o compromessi.

La divulgazione citata non indica quali versioni di Zammad siano vulnerabili. Non specifica nemmeno un intervallo di versioni interessate, la versione correttiva o la configurazione del prodotto necessaria per sfruttare le falle.

Gli amministratori non possono quindi stabilire con certezza se i propri sistemi siano esposti limitandosi a confrontarli con un elenco dettagliato delle versioni vulnerabili. Le indicazioni di DIVD sono più generali: aggiornare alla versione 7 di Zammad, considerata sicura, oppure mettere offline l’istanza il prima possibile.

DIVD ha dichiarato di aver individuato le vulnerabilità insieme a Merlon Security e di aver avvisato Zammad. L’organizzazione stava inoltre informando gli utenti di cui conosceva la presenza di istanze vulnerabili.

Le priorità immediate per gli amministratori

Chi utilizza Zammad dovrebbe considerare l’aggiornamento la misura prioritaria. Se non è possibile passare subito alla versione 7, seguendo le indicazioni di DIVD occorre isolare il sistema o metterlo offline finché non sarà possibile proteggerlo.

Dato che la compromissione descritta ha incluso il dirottamento di sessioni e l’esecuzione di codice con privilegi root, cambiare semplicemente la password potrebbe non bastare se il sistema è già stato sfruttato. Gli amministratori dovrebbero verificare l’host e i servizi collegati per individuare eventuali accessi non autorizzati, escalation dei privilegi e acquisizione di dati.

Tra gli aspetti da verificare:

• Sessioni autenticate anomale o cambiamenti nel comportamento delle sessioni.
• Processi avviati con l’account Zammad che non corrispondono alla normale attività dell’applicazione.
• Tracce di comandi o processi eseguiti con privilegi root.
• Connessioni dall’host Zammad verso servizi interni a cui normalmente non accede.
• Trasferimenti in uscita insoliti o accessi a grandi quantità di dati relativi a ticket e servizi.
• Modifiche ad account, autorizzazioni o configurazioni effettuate durante attività sospette.

Si tratta di indicazioni generali per l’indagine, basate sugli effetti descritti da DIVD, non di indicatori specifici per queste vulnerabilità. Il resoconto citato non fornisce indirizzi IP, hash di file, domini, firme nei log o altri indicatori concreti di compromissione.

Se possibile, prima di ricostruire il sistema o mettere offline un host sospetto, è opportuno conservare i log di sistema, applicazione, autenticazione e rete. Anche la segmentazione tra il server di ticketing e i servizi interni sensibili può limitare ciò che un attaccante riesce a raggiungere dopo la compromissione iniziale, come dimostra il caso di DIVD.

Restano aperte importanti questioni tecniche

L’incidente ha avuto conseguenze gravi, ma lascia irrisolti diversi aspetti necessari per valutare il rischio in modo più ampio. Il resoconto citato non riporta un punteggio CVSS né una valutazione formale della gravità e non identifica le versioni interessate.

Manca inoltre una spiegazione, versione per versione, che distingua le build vulnerabili da quelle corrette. Le informazioni disponibili al pubblico non chiariscono quali richieste siano state usate per sfruttare le falle, quali condizioni di accesso fossero necessarie né quali tracce abbia lasciato la catena d’attacco.

Il resoconto non dimostra neppure che siano stati violati i sistemi di altri clienti di Zammad. L’ambito confermato descritto qui riguarda l’incidente di DIVD e l’attribuzione della compromissione alle due vulnerabilità zero-day.

Per ora, la combinazione di dirottamento delle sessioni, esecuzione di codice da remoto ed escalation a root rende chiare le indicazioni operative: aggiornare alla versione 7 oppure disattivare l’istanza esposta. Per definire con precisione quali installazioni siano interessate e predisporre rilevamenti mirati, serviranno ulteriori risultati dell’indagine di DIVD e informazioni tecniche da parte di Zammad.