Zammad's Two-Flaw Exploit Chain and the Two Affected-Version Lists

TL;DR

• Two Zammad vulnerabilities chain into root: CVE-2026-102489 hijacks a session and reaches remote code execution as the zammad service 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

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.

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.

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.

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.

Sources

Source: DIVD-2026-00015 — Vulnerabilities in Zammad during investigation of case DIVD-2026-00014 — csirt.divd.nl/cases/DIVD-2026-00015/, published 2026-09-29, retrieved 2026-10-04 (CVE-2026-102489 session hijack leading to remote code execution as the zammad user, affected 6.3.0 to 6.5.4 with the defect present in 7.0.0 to 7.1.3 and not exploitable due to environment conditions; CVE-2026-102490 local escalation to root across 1.5.0 to 7.1.0-alpha; recommendation to upgrade to Zammad version 7; patch status available; case status open; last modified 2026-10-01; timeline of 21, 22-23, 24 and 26 September; scanning and owner notification; log check script). Source: CVE-2026-102489 and CVE-2026-102490 records — csirt.divd.nl, published 2026-09-29, retrieved 2026-10-04 (affected and unaffected ranges per CVE; publisher credited to DIVD CSIRT with Merlon Security researchers). Source: DIVD-2026-00014 — When, not if… — csirt.divd.nl/cases/DIVD-2026-00014/, retrieved 2026-10-04 (first access on 21 September 2026, detection on 22 September, datacentre access blocked, forensic investigation with Merlon Security, report to Zammad on 24 September, notification of the Autoriteit Persoonsgegevens and NCSC-NL, worst-case handling and assumption of breach, network segmentation limiting the intrusion, the quoted account of the two zero-days and the agentic mode of operation). Source: Zammad security policy — raw.githubusercontent.com/zammad/zammad/develop/SECURITY.md, retrieved 2026-10-04 (security fixes provided for the current stable version only; older versions unsupported and requiring an update before a report). Source: Zammad 7.2 release page — zammad.com/en/product/releases/7-2, retrieved 2026-10-04 (release dated 23 September 2026; tamper-proof admin audit log whose entries cannot be edited or deleted through the interface or the API; spam protection; AI usage and cost controls; requirement to reindex Elasticsearch after updating; ISO/IEC 27001:2022 certification and SOC 2 Type I). Source: Zammad Zero-Days Exploited in AI-Powered DIVD Hack — securityweek.com, retrieved 2026-10-04 (automated AI attack, two zero-days, CVSS 9.4 in the chained scenario, the quoted DIVD statement on session hijacking, remote code execution and escalation in seconds). Source: Dutch Institute for Vulnerability Disclosure Breached via Zammad 0-Days — hackread.com, retrieved 2026-10-04 (CVE-2026-102489 rated 8.7 alone and 9.4 when chained; CVE-2026-102490 rated 8.5 locally; the vendor's disputed position on affected versions and its statement that it had not received technical details for the second flaw). Source: U.S. CISA adds Zammad GmbH Zammad flaws to its Known Exploited Vulnerabilities catalog — securityaffairs.com, retrieved 2026-10-04 (CISA's 2 October 2026 additions: CVE-2026-102489 as Zammad GmbH Zammad Session Fixation Vulnerability and CVE-2026-102490 as Zammad GmbH Zammad Improper Privilege Management Vulnerability, on evidence of active exploitation). Source: Zammad Vulnerabilities Let Attackers Execute Code and Escalate Privileges to Root — gbhackers.com, retrieved 2026-10-04 (chain description, affected ranges, remediation advice, DIVD IoC script for CVE-2026-102489). Internal linkage: The Zimbra Bug That Turned a Monitoring Add-on into a Command Line. More on Netics' work at infrastructure monitoring with plain-language alerts.

Source: DIVD CSIRT casefiles and CVE records — csirt.divd.nl, published 2026-09-29, retrieved 2026-10-04; Zammad security policy and 7.2 release page — zammad.com, retrieved 2026-10-04; CISA Known Exploited Vulnerabilities catalogue — cisa.gov, retrieved 2026-10-04; SecurityWeek, Hackread, Security Affairs and GBHackers reporting, retrieved 2026-10-04. Figures: screenshots of the official DIVD CSIRT casefile, the vendor release page and the CISA catalogue, captured 2026-10-04.