Two Zammad zero-days hand attackers root access, exploited against disclosure institute DIVD
A chain of two Zammad flaws — session hijacking followed by privilege escalation to root — was exploited against the Dutch Institute for Vulnerability Disclosure on 21 September 2026 and added to CISA’s KEV catalog on 2 October. Move your Zammad instances to version 7 and treat any exposed instance as potentially compromised, because patching alone does not remove an attacker’s persistence.
21 September 2026. An attacker exploits a session hijack to compromise Zammad, the ticketing platform of the DIVD (Dutch Institute for Vulnerability Disclosure) — the very institute whose job is to coordinate the disclosure of flaws. 24 September 2026. The DIVD reports two zero-days to the vendor under case DIVD-2026-00015. 2 October 2026. CISA adds the first flaw, CVE-2026-102489, to its KEV catalog of actively exploited vulnerabilities. Why it matters: the organization that hunts everyone else’s bugs fell victim to its own, and the full chain ends in root access within seconds.
A two-step chain, from session to root
The first flaw, CVE-2026-102489, is a session hijack (CWE-384) affecting Zammad 6.3.0 through 6.5.4. Unauthenticated, it lets an attacker seize a valid session over the network and then execute commands remotely as the zammad service account. The flaw is also present in versions 7.0.0 through 7.1.3, but the DIVD notes it is not exploitable there because of environmental conditions.
The second flaw, CVE-2026-102490, is a local privilege escalation that turns zammad access into root. Its scope is far wider: it affects every version of Zammad, from 1.5.0 all the way to 7.1.0-alpha. In other words, upgrading to version 7 neutralizes the first step but leaves the second intact if an attacker already holds a local shell.
Chained together, the two flaws carry high impact. A remote attacker hijacks a session, runs commands as zammad, then escalates to root: from there they can alter helpdesk data, read customer tickets, steal attachments, modify accounts, plant a persistent backdoor, and pivot into the wider network. The DIVD describes a progression of “a few seconds” between seizing the session and full control, followed by access to other services and data exfiltration.
The symbolic trap: the victim is the disclosure institute
The bitterest lesson here is less about technique than about who the victim is. The DIVD is a volunteer and researcher collective that scans the internet, notifies the owners of vulnerable instances, and coordinates fixes — a role close to CISA in the US or NCSC in the UK. The 21 September 2026 compromise was not discovered proactively: it surfaced incidentally, during the investigation of a separate breach case, DIVD-2026-00014.
The DIVD analyzed and reproduced both flaws between 22 and 23 September, then reported everything to Zammad on 24 September. On 26 September it began scanning internet-exposed Zammad instances and notifying their owners. That timeline says something about how hard this work is: even the actor best positioned to spot a flaw was first a victim, then had to switch into incident mode before it could do its day job of notifying others.
Version 7 or offline: only half reassuring
The official DIVD guidance is to upgrade to Zammad 7, or take the instance offline until the fix is applied. The nuance matters: CVE-2026-102490 also affects version 7, including the latest alpha builds. Moving to 7 cuts off the session hijack, but an operator who already obtained zammad access on an unremediated machine keeps the ability to escalate.
Persistence is the real subject. Because the flaws were exploited before public disclosure, patching does not remove what an attacker already installed. The DIVD published a log-check script that looks for indicators of compromise: suspicious sessions, unexpected administrative activity, unusual command execution, and changes touching the zammad account. That is the first reflex to trigger, before even thinking about the upgrade.
Zammad, a heavily exposed open-source helpdesk
Zammad is an open-source helpdesk, hosted or self-hosted, used by organizations of every size to manage tickets, customers, and incidents. Its popularity makes it a prime target: a poorly exposed instance stacks a web attack surface, a service account that executes code, and — all too often — an SMTP or LDAP integration that opens a door to the rest of the network. The DIVD itself began scanning internet-exposed instances on 26 September to notify their owners, a sign that the exposed population is large enough to justify a notification campaign.
That exposure is why the chain is so dangerous. The session hijack requires no authentication: the instance only needs to be reachable. And because the zammad account executes code, the attacker does not need a privileged user account to get started — the escalation to root does the rest.
What the KEV listing actually changes
The addition of CVE-2026-102489 to CISA’s KEV catalog on 2 October 2026 is not trivial: that catalog only lists flaws with confirmed active exploitation, making it the most reliable severity signal there is, far from a theoretical CVSS score. Under the BOD 22-01 directive, US federal agencies must remediate or mitigate any listed flaw within a bounded window.
The number that should hold your attention is the gap: between the DIVD compromise on 21 September and the KEV listing on 2 October, twelve days passed. That is the window in which attackers exploited the flaw in the wild before the public alert landed. For an organization running Zammad, the question is therefore not “are we vulnerable” but “were we hit during those twelve days”.
What to do
The playbook comes down to four actions, in order.
- 1. Inventory and isolate. List every Zammad instance in your estate, including ones no longer in use. Any internet-exposed, unpatched instance must be taken off the network immediately.
- 2. Look for compromise before patching. Run the DIVD IOC script and review the logs. If suspicious activity shows up, the patch is already too late: treat the machine as compromised.
- 3. Upgrade to version 7 and patch the second flaw. Version 7 neutralizes CVE-2026-102489; apply the fix for CVE-2026-102490 as soon as it ships, since it covers 7 as well.
- 4. Remediate, don’t just patch. Rotate secrets and keys, review accounts, inspect scheduled tasks and services: root access compromises everything the machine can reach, not just the helpdesk.
The wider lesson concerns the target class, not this vendor alone. Helpdesk platforms sit at the intersection of customer data, internal workflows, and authentication integrations such as SMTP or LDAP, which makes them a far higher-value target than their unglamorous reputation suggests. The DIVD case is a reminder that the systems we treat as internal plumbing — ticketing, documentation, support — are often the systems that hold the keys to the rest of the network the moment an attacker obtains a shell on them.
Verdict
If you run an internet-exposed Zammad instance, treat it as potentially compromised until you have run the DIVD IOC script and reviewed the logs: the session flaw was exploited in the wild before it went public. If you are on 6.x, the move to 7 is urgent but not sufficient on its own — the second flaw escalates to root on all versions, and a patch alone does not erase persistence that is already installed. If you think “it only happens to others”, this case proves otherwise: the institute that coordinates vulnerability disclosure was compromised by the exact chain it is now documenting. Full remediation, not the patch, is the only answer that holds.