Zammad zero-days: DIVD breached, in CISA KEV since 2 October, and a dispute over affected versions

On 21 September 2026 an attacker got into the network of the Dutch Institute for Vulnerability Disclosure (DIVD) through DIVD's own Zammad helpdesk. In case file DIVD-2026-00014, DIVD describes two previously unknown flaws that together allowed session hijacking, code execution as the zammad user and privilege escalation to root, "in seconds" according to DIVD. Since 2 October both flaws, CVE-2026-102489 and CVE-2026-102490, are in CISA's KEV catalog; US federal agencies have until 5 October to act. Zammad 7.2.0 hardens the first flaw. For the second there is no confirmed fix as of 3 October.

This is the chain as DIVD describes it:

What DIVD says about the breach

DIVD noticed the intrusion on 22 September, blocked access to all systems in its data centre and started forensics with Merlon Security. In statement 4 of 30 September, DIVD writes that the attacker could reach other services from root and exfiltrate data; proper network segmentation and the work of DIVD's own team stopped them before they got deeper into the network. Statement 5 says volunteer data left the network, such as DIVD email addresses and possibly contact details. DIVD therefore warns about messages from people posing as DIVD volunteers.

DIVD classifies the attacker as an AI agent. The scripts contained comments in which the agent justifies its own actions and explains why what it is doing is "really not phishing"; in DIVD's view a human attacker would not bother. DIVD calls the attack "loud and very messy". The evidence DIVD has published is two redacted screenshots. The AI attribution is DIVD's statement and has not been independently checked. BleepingComputer reported on it on 30 September, also citing DIVD as its source.

Affected versions, and according to whom

DIVD and Zammad disagree about the version ranges. The table separates the statements by source:

DIVD's two statements on the privilege escalation contradict each other: the versions field ends at 7.1.0-alpha, while the summary covers all versions up to the latest alpha. Since 7.2.0 was released on 23 September, the latest alpha in the repository is 7.3.0-alpha. Anyone running 7.2.0 therefore cannot rely on the narrower range for CVE-2026-102490. The "Patch status" field on the DIVD page reads "Available"; as of 3 October the GitHub advisories contain no Zammad advisory for either CVE, and the newest entries date from 25 August. runZero rates the flaws at CVSS 8.7 and 8.5 and notes that the vendor disputes the claims about CVE-2026-102490.

The disclosure dispute

According to DIVD's timeline, the report went to Zammad on 24 September. On 26 September DIVD scanned publicly reachable Zammad instances, published a limited disclosure for both CVEs and started notifying owners of vulnerable instances.

In its statement of 1 October, Zammad writes that it had received no technical details on CVE-2026-102490 and cannot verify a claim it has not been shown. Zammad does not consider publishing a CVE for a flaw the vendor was never told about a responsible way to handle vulnerabilities. A follow-up came that evening: the details had arrived, the flaw cannot be exploited remotely on its own, and an attacker would already need access to the server. At DIVD, CVE-2026-102489 provided exactly that access.

CISA lists both entries with forensicTriage: Yes in the KEV catalog. Under directive BOD 26-04 this means US federal agencies must also check whether a system was already compromised before the patch was applied. That is not binding for companies outside the US federal government, though the same order of steps makes sense there too.

What to do now

Our Zammad ran 7.0.0-9 until the evening of 3 October and has run 7.2.0 since. As of today that does not help against CVE-2026-102490, which has no confirmed fix yet. For your own instances the order is the one described in patch management for SMEs, here with a fixed priority:

1. Find out the version. Anything up to 6.5 is out of support and, according to both sources, attackable from outside through CVE-2026-102489. Update those instances immediately or take them offline, as DIVD recommends.
2. Update to Zammad 7.2.0, the current stable release.
3. Check the logs. DIVD provides a check script for Zammad logs; by default it searches /var/log/zammad and /var/log/nginx and also reads compressed files. Docker installations keep their logs elsewhere, and the paths can be passed as arguments.
4. Restrict reachability. A helpdesk has to be reachable for customers, the agent interface often does not. Where possible, put the agent login behind a VPN or an IP allowlist.
5. Isolate the Zammad server so that root there opens no path to other services. At DIVD, that is what limited the damage.
6. Watch Zammad's GitHub advisories and apply the fix for CVE-2026-102490 as soon as it appears.

If you are only introducing Zammad, setup and operation are covered in the post on the Zammad helpdesk. Which versions CVE-2026-102490 actually affects, and whether 7.2.0 is among them, remains open until the vendor publishes its advisory.

Further sources

• DIVD-2026-00014, case file on the DIVD breach with five statements and a timeline
• DIVD-2026-00015, case file on CVE-2026-102489 and CVE-2026-102490 with version ranges
• DIVD check script for Zammad logs, indicators of CVE-2026-102489
• Zammad statement of 1 October 2026 with follow-up on CVE-2026-102490
• CISA alert of 2 October 2026 on the KEV additions
• CISA Known Exploited Vulnerabilities Catalog
• Zammad security advisories on GitHub
• Zammad tags on GitHub, including 7.2.0 and 7.3.0-alpha
• runZero, summary with CVSS scores
• BleepingComputer, report of 30 September 2026