CISA put Zammad on KEV. 7.2 is the session close. The root bug is still a fight.

CVE-2026-102489 and CVE-2026-102490 are a session-to-root chain. CISA due date is 5 October. Zammad has not confirmed the LPE.

RWP Ventures · 2026-10-03 · event 2026-10-02 · 15 min read · priority 8.9

The product is Zammad GmbH Zammad, the open-source helpdesk. CVE-2026-102489 is session fixation that can lead to remote code execution as the zammad user (CWE-384). CVE-2026-102490 is improper privilege management that can let that local user become root (CWE-269). NVD’s 3.1 scores are 9.8 on both (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). DIVD’s chained CVSS 4.0 is 9.4. CISA SSVC on 2 October: exploitation active, technical impact total; automatable yes on 489, no on 490.

Do not collapse four facts.

1. The KEV clock is not a patch clock for the whole chain. NCSC-NL (advisory NCSC-2026-0396, 30 September) says Zammad shipped updates for CVE-2026-102489 and that CVE-2026-102490 is not yet remediated. Zammad’s 1 October community statement recommends 7.2.0 for the session bug and says it has received no technical details on the LPE. A change ticket that says “upgrade to 7” closes the entry DIVD and NCSC describe. It does not, on this record, close the root step.
2. 6.5.4 is not a settled floor. DIVD’s case file and NCSC-NL write 6.3.0 through 6.5.4 as in for 489. DIVD’s own CVE JSON and NVD CPE cut before 6.5.4. Treat 6.5.4 as IN until the vendor names it out. Zammad’s policy is that 6.5 is end of support and they will not back-port.
3. 7.x is not a single answer. DIVD: the 489 defect is present on 7.0.0–7.1.3 but not exploitable due to environment conditions; 490 runs from 1.5.0 through 7.1.0-alpha / “all versions including the latest alpha.” Zammad: 7.0 and later are not affected by 489; they still hardened the code in 7.2.0; 490 is unverified. Those two sentences can both be in the ticket. They are not the same sentence.
4. Yesterday’s FortiMail clock did not pause. Catalog 2026.10.01 added FortiMail CVE-2026-104286 (due 4 October; fixed builds still upcoming as of yesterday). Catalog 2026.09.30 added Cisco SD-WAN Manager CVE-2026-76504 (due today, 3 October). Those tickets stay open. The new operational ticket is the helpdesk.

What happened

Friday 2 October, CISA put both CVEs on KEV. The exploitation evidence is older than the catalog row.

The Dutch Institute for Vulnerability Disclosure is a CNA. On 21 September an attacker reached DIVD’s own systems through Zammad. DIVD noticed the next day, blocked datacenter access, stood up IR with Merlon Security, reported to Zammad on 24 September, and started notifying other internet-facing Zammad owners on 26 September. Case DIVD-2026-00014 is the breach. Case DIVD-2026-00015 is the product. CVE records published 30 September.

DIVD’s sentence, 30 September: the two bugs together allowed session hijacking, remote code execution, and privilege escalation from the Zammad user to root, “in seconds.” From there the actor reached other services and exfiltrated data. Segmentation and IR stopped deeper movement. On 1 October DIVD said volunteer data got out — DIVD email addresses and possibly contact details — and told anyone who gets an off-feeling message from a DIVD volunteer to verify at communications@divd.nl.

DIVD assessed the tradecraft as agentic AI: logs showed scripts with notes in which the agent justified its own actions. That is DIVD’s assessment of its own incident, not a CISA attribution and not a named cluster. CISA’s KEV rows do not mention AI. Confidence on “an autonomous agent ran the chain against DIVD”: moderate, because the victim published it and no contradictory forensic account is public. Confidence that every other Zammad hit is an AI agent: low. Do not write that.

NCSC-NL on 30 September: both bugs have been actively abused at least since 21 September to obtain root on the host that runs Zammad. Copy application and network logs before you install the 489 update, because those logs are how you later decide whether the box was hit in the zero-day window. Contact the vendor on 490.

Zammad’s 1 October statement, posted on the community thread CISA itself linked in the KEV notes:

• 489: they first received a report in August 2026. Exploitation is only possible on 6.5 and older because of the runtime those versions use. 6.5 is out of support. 7.0 and later are not affected. They still hardened the code in 7.2.0 (released 23 September).
• 490: DIVD has not given Zammad technical details. They cannot confirm the vulnerability, its scope, or the affected versions. They have formally asked. Watch GitHub security advisories. As of this retrieval, zammad/zammad has no GHSA that names either CVE.
• Disclosure: DIVD reported 24 September and scanned/disclosed 26 September. Zammad does not consider that coordinated.

RWP is not picking a winner between a CNA that was the victim and a vendor that says it was not given the LPE. The operational fact is the split. Hunt as if 490 is live. Do not wait for the GitHub advisory to exist before you inventory.

Why it matters

Zammad is not a VPN. It is the box that holds tickets, attachments, mailbox credentials, LDAP/SSO, and customer PII — often internet-facing, often on Docker, often run by teams who treat “helpdesk” as low-tier infra. Session-to-zammad-to-root on that host is not “a Rails CVE.” It is a path to the case file, the mailbox the queue is bound to, and then the rest of the Linux host.

Three operational lies are now in the ticket.

1. “We are on 7, so KEV does not apply.” Incomplete. CISA listed both CVEs against Zammad, due 5 October, forensic triage Yes. DIVD still writes 490 across current trains. Zammad still has not published a 490 fix. BOD 26-04 still wants FCEB to check whether the actor was on the box. A version string is not a triage.
2. “Upgrade is the hunt.” NCSC-NL’s order is preserve logs, then update 489, then deal with 490 as unpatched. DIVD published a logfile check script for 489. A clean run on rotated logs is not a clean host. Root on 21–22 September would not be evicted by a 7.2 package on 3 October.
3. “The AI story is the vulnerability.” The KEV rows are session fixation and privilege management. DIVD’s agent narrative is how one intrusion looked in their logs. It does not change the patch, the due date, or the need to pull internet-facing 6.5 off the wire.

A Zammad that also queues industrial or safety-system tickets is still an IT helpdesk compromise until evidence shows process impact. None is in this record.

Who / what is affected

Zammad is not Jira, ServiceNow, osTicket, Freshdesk, or GitLab. Do not collapse this pair onto CVE-2026-90970 (GitLab AI Gateway, 2 October, CVSS 9.9, not on KEV).

Technical context

RWP is not reproducing session-fixation request paths, cookie handling, or the local root step. The defender cut is enough.

CISA’s catalog language: 489 is session fixation leading to RCE as zammad, chainable with 490. 490 is improper privilege management allowing the local zammad user to escalate to root, chainable with 489. Platforms in the CNA record: Linux and Docker.

DIVD: 489 is network-reachable, privileges none, user interaction passive on the 4.0 vector, exploit maturity Attacked, automatable yes. 490 alone is local, low privileges. Chained, both become network / none / 9.4.

What to hunt, from published guidance — logs and host artifacts, not an exploit path:

• Inventory every Zammad: package, container tag, Helm chart, cloud tenant. Record the running version, not the last change ticket.
• Whether the HTTP/HTTPS listener is reachable from an untrusted network. Internet-facing 6.5 is the 489 precondition DIVD and NCSC describe.
• Copy /var/log/zammad and reverse-proxy logs off-box before you upgrade or rebuild. NCSC-NL asked for that order for a reason.
• DIVD’s 489 logfile check (case DIVD-2026-00015). A hit is a lead. A miss is not a close.
• Process and file anomalies as zammad or root that do not belong to the app: shells, unexpected outbound, new cron, new SSH keys, new containers.
• Mailbox, OAuth, LDAP, and API credentials the instance holds. DIVD’s own impact was volunteer contact data leaving through that path.
• 7.2.0 actually running, not merely “we have a 7.x image in the registry.”

ATT&CK mapping for the ticket, not a kill chain we ran:

No public proof-of-concept is in this assessment. We will not publish one.

Threat / exploitation status

Confidence on the KEV add, the DIVD victim, the due date, and the 489/490 split: high. Confidence on actor, victim census, and whether 7.2.0 silently closed 490: low. Confidence that every internet-facing 6.5 is already rooted: low — reachability plus the 21 September start date are not a census.

What defenders should do

1. Inventory every Zammad — VM, Docker, Kubernetes, lab, DR, managed host, vendor SaaS tenant. Record the running version against DIVD-2026-00015 and Zammad 7.2.0, not against a scanner CPE that stops at 6.5.4 or skips 7.x. If you run 6.5.4, do not write “not in scope” from the JSON lessThan.
2. If 6.5 or older is internet-facing, treat that as the 489 exploit condition. Upgrade to 7.2.0 or take the instance offline today. EOL 6.5 will not get a back-port. That is Zammad’s published policy.
3. Preserve, then hunt, then upgrade. Snapshot logs and the host off-box first. NCSC-NL: those logs are how you later decide whether you were hit in the zero-day window. Run DIVD’s 489 check. Look for zammad-user and root artifacts that are not the app. BOD 26-04: a later package can destroy the evidence.
4. Do not declare 490 closed because you landed on 7.2.0. NCSC-NL still says it is unpatched. Zammad still says it has no details. Constrain the host: no internet to the helpdesk unless required, no shared secrets with the rest of the estate, no leftover zammad sudo/docker-socket that turns a service user into the hypervisor. Open a vendor case that names CVE-2026-102490.
5. If you find 489 IoCs or unexplained root: isolate, rebuild, rotate. Mailbox passwords, OAuth grants, LDAP binds, API tokens, SSH keys on that host, and any trust downstream systems placed in that queue. DIVD’s own lesson was impersonation of volunteers. Do not “clean” a rooted Docker host and return it to ticket duty.
6. SaaS / Zammad Cloud tenants: ask, do not assume. The KEV rows do not name the cloud SKU. Get a written version and a written 490 answer.
7. Keep the rest of this window on the board. Cisco SD-WAN Manager CVE-2026-76504 is KEV, due today, 3 October. FortiMail CVE-2026-104286 is KEV, due 4 October, firmware still upcoming as of yesterday. NetScaler 88771/88772 were due 30 September. The helpdesk is today’s interrupt; those clocks did not pause.

RWP assessment

Score 8.9.

Highest-leverage development since yesterday’s FortiMail hunt is a new two-row KEV add on a commonly internet-facing helpdesk: session to zammad to root, forensic triage Yes, due 5 October, a named victim that is itself a CNA, and a vendor/researcher split on whether the LPE even exists as described. Evidence quality is high on the catalog and the victim timeline (CISA JSON, DIVD case files, CVE/NVD, NCSC-NL). Evidence quality is intentionally split on 490’s remaining scope — that split is the story, not a reason to wait.

It outranks a second day on FortiMail CVE-2026-104286 because yesterday already assessed that file-write; the due date is tomorrow, not a new exploitation picture, and the firmware is still a wait. It outranks Cisco CVE-2026-76504 because that API bypass was Daily Top on 1 October; today’s due date is a clock. It outranks GitLab AI Gateway CVE-2026-90970 (CVSS 9.9, 2 October) because GitLab-hosted is already patched, the bug is authenticated Duo-Agent, and it is not on KEV. It outranks Dell CSM CVE-2026-63688 / 63692 (CVSS 10, DSA-2026-448) because Dell has not claimed in-the-wild use. It outranks the 1 October CISA ICS batch and the ACSC NetScaler SAML note because those are either no-wild or a continuation of the 28 September NetScaler story.

What we are not saying: that a named APT owns this pair; that ransomware is using it; that every 7.x box is exploitable for 489; that 7.2.0 silently fixed 490; that “agentic AI” is a new vulnerability class CISA catalogued; that a helpdesk journaling an industrial site is confirmed process impact; that DIVD’s volunteer-email loss is a census of other victims.

What we are watching

• Whether Zammad publishes a GHSA or a 7.2.x/7.3 that names CVE-2026-102490, or continues to say it has no details.
• Whether 6.5.4 is inclusive or exclusive, in writing, from the vendor.
• Whether DIVD’s owner-notification scan becomes a public count, a sector mix, or a second named victim.
• Whether CISA or NCSC-NL revises the automatable / chain language.
• Cisco CVE-2026-76504 due today and FortiMail CVE-2026-104286 due 4 October — clocks, not this story.
• Whether a public PoC appears. We will not publish one.

Sources

• CISA — Adds two known exploited vulnerabilities (2 October 2026)
• CISA — KEV JSON catalog 2026.10.02
• CISA — Known Exploited Vulnerabilities Catalog
• CISA — BOD 26-04
• DIVD — DIVD-2026-00015 (Zammad CVEs)
• DIVD — DIVD-2026-00014 (breach)
• DIVD — CVE-2026-102489 · CVE-2026-102490
• CVE-2026-102489 · NVD
• CVE-2026-102490 · NVD
• NCSC-NL — NCSC-2026-0396
• NCSC-NL — Actief misbruik van zeroday-kwetsbaarheden in Zammad
• Zammad Community — vendor statement on DIVD-2026-00015
• Zammad — 7.2 release
• SecurityWeek — Zammad zero-days exploited in AI-powered DIVD hack
• The Register — AI agents hacked the hackers