// 2 CRITICAL · 2 ZERO-DAY · 3 CVE · 4 EXPLOIT · 1 ADVISORY NELLE ULTIME 24H→
CISA ha aggiunto due vulnerabilità zero-day in Zammad al catalogo KEV con CVSS 9.4. Le agenzie federali devono aggiornare entro il 5 ottobre 2026. La catena di

Il 2 ottobre 2026 CISA ha inserito nel suo Known Exploited Vulnerabilities Catalog due vulnerabilità zero-day in Zammad GmbH Zammad, il sistema di ticketing open-source. Le agenzie federali statunitensi appartenenti al Federal Civilian Executive Branch (FCEB) hanno tempo fino al 5 ottobre 2026 per applicare le patch, secondo le disposizioni del Binding Operational Directive 26-04. La scoperta delle due falle è avvenuta in circostanze particolari: sono emerse durante l'incident response del Dutch Institute for Vulnerability Disclosure (DIVD), che era stato compromesso proprio attraverso il proprio sistema di ticketing.

Punti chiave
  • CVE-2026-102489 (session fixation con RCE come utente zammad) e CVE-2026-102490 (improper privilege management per escalation a root) sono entrambe nel KEV di CISA con scadenza 5 ottobre 2026
  • Le due vulnerabilità formano una catena di exploit che consente compromissione completa del sistema bersaglio
  • La scoperta è avvenuta durante l'incident response di DIVD dopo una breach del proprio sistema Zammad
  • CVE.org riporta per CVE-2026-102489 un doppio punteggio CVSS 4.0 (8.7 HIGH e 9.4 CRITICAL) con vettori diversi, mentre Security Affairs indica 9.4 per entrambe le CVE

Il meccanismo della catena: da session hijack a root

La prima vulnerabilità, CVE-2026-102489, è una falla di session fixation che CISA descrive nel KEV come in grado di portare a remote code execution con i privilegi dell'utente di servizio zammad. Il record CVE.org la classifica come session hijack vulnerability with remote code execution. La seconda, CVE-2026-102490, è una vulnerabilità di improper privilege management che permette all'utente locale zammad di scalare i privilegi fino a root.

CISA ha esplicitamente documentato la concatenabilità delle due falle: nel catalogo KEV, entrambe le voci riportano l'indicazione che possono essere concatenate con l'altra CVE. Questa architettura di attacco è particolarmente efficiente perché sfrutta una prima compromissione remota per poi elevare i privilegi a livello di sistema operativo, ottenendo il controllo completo della macchina target.

I punteggi CVSS: un sistema in transizione

La valutazione del rischio presenta una complessità aggiuntiva legata alla transizione verso CVSS 4.0. Secondo Security Affairs, entrambe le vulnerabilità hanno un punteggio di 9.4. Il record ufficiale su CVE.org per CVE-2026-102489 mostra invece due punteggi distinti: 8.7 HIGH e 9.4 CRITICAL, associati a vettori CVSS:4.0 con scope di impatto diverso. Questa duplicazione riflette la granularità del nuovo sistema di scoring, che distingue metriche ambientali e di impatto specifico, ma può generare incertezza nella prioritizzazione operativa.

Per CVE-2026-102490 non è disponibile nel dossier il doppio punteggio su CVE.org: la fonte indica 9.4 attraverso Security Affairs. La discrepanza tra le fonti sul primo identificatore suggerisce che le organizzazioni debbano verificare direttamente i vettori ufficiali piuttosto che affidarsi a riassunti aggregati.

Versioni affette e distribuzione del software

Le versioni interessate presentano pattern diversi tra le due vulnerabilità. CVE-2026-102489 colpisce Zammad dalla versione 6.3.0 alla 6.5.4 e dalle versioni 7.0.0 alla 7.1.3, con l'annotazione di CVE.org che le versioni 7.x non sarebbero esploitabili a causa di condizioni ambientali specifiche. CVE-2026-102490 ha invece un range più ampio, estendendosi dalla versione 1.5.0 fino alla 7.1.0-alpha.

Zammad è un prodotto con oltre 2.000 clienti e più di 55.000 utenti attivi, secondo i dati citati da Security Affairs. La sua natura open-source e il ruolo di sistema di ticketing lo rendono un componente critico dell'infrastruttura di molte organizzazioni, inclusi soggetti che si occupano proprio di sicurezza informatica.

La vicenda DIVD: quando chi scopre falle viene colpito

L'elemento narrativo più rilevante della vicenda è la provenienza della scoperta. DIVD, istituto olandese specializzato nella divulgazione responsabile di vulnerabilità, ha subito una compromissione del proprio sistema di ticketing basato su Zammad. Durante l'analisi forense dell'incidente, l'organizzazione ha identificato le due zero-day che stavano dietro all'attacco.

"When hackers get hacked, we deal with it in hacker style. While trying to figure out how the attackers got into our own systems, we found two zero-day vulnerabilities in Zammad." — DIVD, citato da Security Affairs

DIVD ha collaborato con Merlon Security, in particolare con Tijmen van der Spijk, per l'analisi tecnica. Il nome del ricercatore compare come finder nel record CVE.org. L'organizzazione olandese ha dichiarato che "some damage had already occurred" prima della scoperta, senza tuttavia dettagliare la natura o l'estensione dei dati compromessi.

Il dossier non specifica la data esatta della breach DIVD, né l'identità degli attaccanti. Security Affairs riferisce che DIVD aveva indicato un aggiornamento pubblico atteso per il 1 ottobre, ma il contesto temporale rimane parzialmente indeterminato tra le fonti. L'elemento descritto da Security Affairs come "agentic part of this hack" — riferito a un presunto componente di automazione basato su AI — proviene esclusivamente dalla citazione DIVD su LinkedIn e non è confermato da fonti indipendenti nel dossier.

Cosa fare adesso

  • Aggiornare Zammad alla versione 7, indicata da DIVD come fix definitiva per entrambe le vulnerabilità
  • Eseguire forensics triage per verificare eventuali compromissioni precedenti all'applicazione della patch, come richiesto esplicitamente da BOD 26-04 per le agenzie FCEB
  • Valutare la disconnessione temporanea del sistema se l'aggiornamento non è immediatamente applicabile, seguendo la raccomandazione di DIVD
  • Verificare direttamente su CVE.org i vettori CVSS 4.0 specifici per la propria versione, data la presenza di punteggi multipli per CVE-2026-102489

Accelerazione del KEV e nuove aspettative di triage

L'inclusione nel catalogo KEV con scadenza a tre giorni dalla pubblicazione è coerente con l'orientamento di CISA a comprimere i tempi di risposta per vulnerabilità con evidenza di sfruttamento attivo. Il BOD 26-04 non impone solo la patch, ma aggiunge il requisito di forensics triage: le agenzie devono dimostrare di aver verificato la presenza o l'assenza di attività ostile precedenti alla mitigazione. Questo segna una progressiva formalizzazione della fase post-patch, che non è più considerata conclusione dell'incidente ma parte integrante del ciclo di remediation.

La vicenda solleva inoltre una questione strutturale per il settore della sicurezza: organizzazioni il cui modello operativo include la gestione di dati sensibili di terzi — vulnerabilità, segnalazioni, comunicazioni con i vendor — possono diventare target di alto valore proprio per la natura delle informazioni che detengono. La compromissione di un sistema di ticketing non è un incidente accessorio se quel sistema archivia dettagli non ancora pubblici su falle in prodotti terzi.

L'assenza di attribuzione e l'impossibilità di verificare indipendentemente il componente "AI agent" descritto da DIVD lasciano aperti interrogativi sulla natura complessiva dell'attacco. Ciò che è documentato — la catena di exploit, la velocità di inclusione nel KEV, la scadenza vincolante — è sufficiente a stabilire la criticità del caso senza aggiungere speculazioni.

Fonti

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. securityaffairs.com
  2. cisa.gov
  3. infosectoday.io
  4. cve.org