A hypothetical: suppose your help desk box gets popped on a Sunday. Nobody notices until Monday, and by then the attacker has gone from the ticketing app to root and is poking at other services on the network. Now suppose your entire job is telling other people about their vulnerabilities. That is roughly what the Dutch Institute for Vulnerability Disclosure says happened to it, and the Zammad zero-day DIVD breach is the best argument I have seen in a while for taking help desk security as seriously as the domain controller.
DIVD is a mostly volunteer group that finds flaws, reports them to vendors, and warns the owners of exposed systems. On its DIVD-2026-00014 case page it puts it bluntly: “DIVD got hacked through AI agents.” Here is what the group has said, what it has not, and what I would do about it.
The Zammad Zero-Day DIVD Breach: What DIVD Says Happened
According to DIVD’s timeline, the first malicious access to its systems came on September 21, 2026. DIVD spotted the activity on September 22, blocked access to everything in its datacenter, and started a forensic investigation with Merlon Security.
DIVD’s September 30 statement says the attackers got in through two zero-days in Zammad, the open-source ticketing system. Together the flaws “allowed session hijacking, remote code execution and privilege escalation from the Zammad user to root, in seconds due to the agentic part of this hack.” From there, DIVD says, the attackers could reach other services and exfiltrate data. DIVD credits network segmentation and fast work by its IT and incident response team for stopping them from going deeper. It also says it is assuming breach until it can prove otherwise.
The AI part rests on DIVD’s own reading of the logs. DIVD says the agent decided each next step itself, fast and on sloppy logic. Its scripts carried comments justifying its own actions, which DIVD notes a human attacker would not bother writing. The attack was, in DIVD’s words, “loud and very messy.”
The Two Flaws, Without the Hype
DIVD opened a second case, DIVD-2026-00015, to track the bugs and notify owners of vulnerable instances. The details matter, because several write-ups flattened them:
- CVE-2026-102489 is a session hijack that leads to remote code execution as the zammad user. DIVD lists Zammad 6.3.0 through 6.5.4 as exploitable. The code is also present in 7.0.0 through 7.1.3 but, per DIVD, is not exploitable there because of the runtime environment. DIVD scores it 8.7 on its own.
- CVE-2026-102490 is a local privilege escalation from the zammad user to root. DIVD lists versions 1.5.0 up to the 7.1.0 alpha and describes it as affecting all versions, including the latest alpha. DIVD scores it 8.5 on its own.
DIVD gives both a 9.4 critical score when they are chained, and that number is the honest headline. Neither bug alone hands a stranger root. Together they did. CISA added both CVEs to its Known Exploited Vulnerabilities catalog on October 2.
Patch Status as of October 6, 2026
This is still moving, so I am pinning it to a date. As of the afternoon of October 6, 2026, here is the status per Zammad’s October 5 security advisory.
For CVE-2026-102489, Zammad says 7.0 and later are not affected in practice. It says exploitation only works on 6.5 and earlier, which are out of support and no longer get security updates. It also says it first received a report on the issue in August 2026, and that a hardening change to the affected code shipped in 7.2.0.
For CVE-2026-102490, Zammad calls it a local privilege escalation that cannot be exploited remotely on its own, and ties it to a confirmed vulnerability in packager.io. Its wording is that the team “is working on a solution.” I found no fix announced. The Zammad 7.2.1 release notes, published October 6, do not mention this CVE. Zammad also says 102490 went public before it had the details to reproduce it, a disclosure dispute I will leave to the two parties.
What Got Out, and What Nobody Knows Yet
Early coverage, including Help Net Security’s October 1 report, said DIVD had not yet shared which data was accessed. DIVD’s own statement from the same day goes a bit further. Volunteer data got out, “such as DIVD email addresses and possibly contact details.” DIVD says whose data and exactly which data are still under investigation, and warns that it is now easier for someone to pose as a DIVD volunteer. That is all DIVD has confirmed about the data.
The same goes for who did it. DIVD says it sees no link to any known public threat actor. It also says no facts so far point to a deliberate, targeted attack on its most sensitive assets, though it cannot rule that out.
Why Help Desk Security Belongs on the Critical List
Opinion: I would call the help desk crown-jewel infrastructure. That is my label, not DIVD’s. The case is simple. Think about what a typical ticket queue holds in most shops, not DIVD’s specifically: password reset threads, screenshots of admin consoles, VPN error messages with hostnames in them, and the email address of every user who ever asked for help. It usually holds a mail integration, often an LDAP or SSO hookup, and API tokens for other systems. It is internet-facing by design, because customers and staff need to reach it. And in a lot of shops it is the app nobody owns after the install weekend.
DIVD’s story has the shape of every bad night I remember: an old version, a half-known bug, and a service account one step from root. The difference is speed. If an agent can chain those steps in seconds, the gap between “first access” and “it reached the next box” is shorter than your alert routing.
What I Would Do This Week
- Check your version today. If you are on Zammad 6.5 or older, you are on unsupported code that is exploitable for 102489. Upgrade, or follow DIVD’s advice and take the instance offline until you can.
- Copy your logs before you upgrade. Help Net reports that the Dutch NCSC recommends keeping application and network logs, which will help if more details on the second flaw emerge. DIVD also publishes an indicator-of-compromise log check script on its case page.
- Lock down the server, not just the app. Zammad’s own guidance is to restrict access to the underlying server to trusted administrators. Since 102490 has no announced fix, assume anything running as the zammad user could become root.
- Segment it like it matters. DIVD credits segmentation with limiting the damage. The help desk host should not be able to reach everything else just because it is internal.
- Watch the vendor channel. Keep an eye on Zammad’s security advisories for the 102490 fix.
DIVD deserves credit for publishing this in near real time, embarrassing parts included. The least we can do is look at our own ticket queues.