TL;DR
- Two Zammad vulnerabilities chain into root: CVE-2026-102489 hijacks a session and reaches remote code execution as the
zammadservice user, and CVE-2026-102490 escalates that local user to root. - The episode behind the disclosure is striking on its own: the organisation that found the flaws is DIVD, and it found them while investigating the breach of its own environment, which it describes in the casefile as an agentic AI powered attack that reached privilege escalation in seconds.
- The parties agree that Zammad 6.3.0 through 6.5.4 is remotely exploitable, and the disagreement starts after that: DIVD records the defect as present in 7.0.0 to 7.1.3, while the vendor reads those releases as unaffected in practice.
- Zammad's own security policy covers the current stable release only, which turns the affected-version question into a support question as well as a technical one.
- Both CVEs entered CISA's exploited-vulnerability catalogue on 2 October 2026, so the timeline for a self-hosted instance is short.
What the two flaws do together
Screenshot of the official DIVD CSIRT casefile (csirt.divd.nl/cases/DIVD-2026-00015/, captured 2026-10-04): the case reference, the two CVEs, the version ranges and the timeline from first abuse to owner notification.
The DIVD CSIRT casefile describes a chain rather than a bug list. CVE-2026-102489 is a session hijack in Zammad that leads to remote code execution as the zammad user; CVE-2026-102490 is a local escalation that lets that same user reach root. Read as a pair, the first flaw gets code running under an application account that can see ticket data, attachments, configuration and whatever credentials the help desk holds, and the second removes the boundary that would normally keep a compromised service account contained.
The casefile is also unusually candid about how the flaws surfaced. During the investigation of case DIVD-2026-00014, two new CVEs were identified — the case that exists because DIVD's own systems were breached on 21 September 2026 through those same two flaws. DIVD's account of the intrusion states that the attackers got in through two zero-days in Zammad that together 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."
That phrase is the part worth keeping. The technical severity of a session hijack is familiar; the operational tempo of an attack that chains one into a root escalation in seconds is what changes the defender's arithmetic. Detection windows measured in hours assume an attacker who moves at human speed through systems that were not built to be read at machine speed.
Two version lists, one disagreement
Version lists are where these cases get decided for a defender, and this one has two, published by two parties with different obligations.
DIVD's list is a security researcher's list. It records Zammad 6.3.0 to 6.5.4 as affected for the remote code execution, states that the defect is also present in 7.0.0 to 7.1.3 where it is "not exploitable due to environments conditions", and records the local escalation against 1.5.0 up to 7.1.0-alpha in the case summary, while the CVE text says it affects all versions of Zammad including the latest alpha. Its recommendation is blunt: "Upgrade to Zammad version 7." Patch status is listed as available, the case remains open, and DIVD has published a log check script and is scanning for exposed instances to notify their owners.
Netics editorial timeline, drawn from the DIVD casefiles: first abuse on 21 September, reproduction by 23 September, report to the vendor on 24 September, and scanning with owner notification from 26 September.
The vendor's list is a support list, and it reads differently in the reporting. Zammad's position, as recorded by Hackread, is that CVE-2026-102489 is exploitable only on unsupported 6.5 and older releases and that 7.0 and later are unaffected in practice; that it hardened the relevant code in version 7.2.0 regardless; and that for CVE-2026-102490 it had not received technical details and therefore could not verify the vulnerability, its scope or its affected versions.
Both positions are defensible, and the gap between them is the interesting part. "The vulnerable code is present but we cannot exploit it in this configuration" and "this release is not affected in practice" are different claims with different consequences for a patch decision. A team on 7.1 that treats the release as clean skips an upgrade; a team that treats the code as present schedules it.
A vendor whose fixes cover the current release
One line in Zammad's security policy explains most of the divergence: the project provides security fixes for the current stable version only, and an older version counts as unsupported, needing an update before a report is even accepted. That is a normal policy for an open-source project with a commercial vendor behind it, and it is worth stating plainly on both sides of the argument. For the vendor, a flaw in an unsupported branch is a reason to upgrade rather than a reason to backport. For the operator, the same policy means the practical fix for anything old is a version jump, with the migration testing that implies.
There is a hard fact underneath the disagreement that a reader should carry past both lists: the local escalation is recorded against a very wide range: 1.5.0 up to 7.1.0-alpha in the case summary, and every version including the latest alpha in the CVE text. That covers releases that have been out of support for years, which in practice describes a lot of self-hosted help desks, because ticketing systems age well and rarely earn an upgrade on their own merits.
Zammad 7.2 arrived on 23 September 2026, the day before DIVD reported the flaws, and it is worth reading for what the vendor chose to ship: a tamper-proof administrative audit log whose entries cannot be edited or deleted through the interface or the API, alongside spam protection and controls on AI usage and cost. An audit log that administrators cannot rewrite is a useful thing to have in the same month your product appears in a breach write-up. It also says something about the direction of travel for self-hosted tools: the operational record is becoming a product feature rather than a log file nobody reads.
Screenshot of the vendor's own release page (zammad.com/en/product/releases/7-2, captured 2026-10-04): Zammad 7.2, published 23 September 2026, the release the vendor points operators to for the hardening and the audit log.
What the disclosing organisation's own breach adds
DIVD's incident casefile is the other half of this story, and it is the half that most security write-ups skip. The institute detected malicious activity on 22 September, blocked access to its datacentre systems, brought in Merlon Security for forensic work, and reported the flaw to Zammad on 24 September. It informed the Dutch data protection authority and the national cyber security centre, and discussed its options with the police. It also wrote the sentence that more organisations should copy: until proven otherwise, the case is handled as a worst case and treated as a breach.
The outcome contains a lesson about architecture rather than tooling. Network segmentation and the incident response team's actions stopped the attackers from going deeper, and the systems that were already outside the affected estate — accounting, banking — showed no evidence of compromise. A help desk that talks to everything is a single point of failure with a friendly interface.
A remediation order for a self-hosted help desk
For anyone running Zammad on their own infrastructure, the sequence that follows from the casefiles is short. Identify the running version first, since the answer decides how much of the rest matters. Treat 6.3.0 through 6.5.4 as an incident-response problem rather than a maintenance one: preserve application and web server logs before touching anything, restrict public exposure, and rotate the credentials the help desk holds. Plan the move to 7.2 or later for the rest of the estate, and read the upgrade notes before the window — the 7.2 audit log requires an Elasticsearch reindex, which is exactly the kind of task that turns a planned hour into an unplanned evening. The log check script DIVD published is worth running on 6.x instances, and the exercise is worth repeating for the rest of your self-hosted stack, because the same pattern — a wide affected range, a current-release support policy and a fast exploitation window — appears in most of it.
Screenshot of the official CISA Known Exploited Vulnerabilities catalogue (cisa.gov, captured 2026-10-04): the catalogue both Zammad CVEs entered on 2 October 2026 on evidence of active exploitation.
Monitoring helps here, and its limits are worth naming: an alert on a web shell or an unusual command line arrives after the attacker has a foothold, which is why the log check matters and why infrastructure monitoring with plain-language alerts is only as good as the events it receives. Our earlier analysis of the Zimbra command injection covers the other half of this pattern, where a patched flaw stayed exploitable in the field for weeks after the fix shipped.
Originally published on the Netics blog.
Top comments (1)
tr.ee/dev-to