Zammad Zero-Day Chain Exploited by AI Agent: Patch Now

An attacker — reportedly an autonomous AI agent — broke into the network of the Dutch Institute for Vulnerability Disclosure (DIVD) on September 21, 2026, using a chain of two previously undisclosed Zammad flaws. DIVD and Merlon Security publicly disclosed the pair on September 29, 2026, as CVE-2026-102489 (an unauthenticated session-fixation bug leading to remote code execution) and CVE-2026-102490 (a local privilege escalation from the low-privilege "zammad" account to root). Chained together, the two give an attacker root on a Zammad server with no valid credentials at all. CISA added both to its Known Exploited Vulnerabilities (KEV) catalog on October 2, 2026, with a remediation deadline of October 5, 2026, for federal agencies. If you self-host Zammad, the open-source helpdesk and ticketing platform, patch now.

What happened

DIVD — the volunteer-run Dutch nonprofit that coordinates vulnerability disclosure across the industry — discovered it had been breached on September 22, 2026, when its own team spotted and blocked anomalous activity on its network. Investigating how the intruder got in led DIVD and researchers from Merlon Security to two previously unknown flaws in Zammad, the open-source helpdesk software DIVD uses internally. According to DIVD's account of the incident, the initial malicious access had occurred the day before, on September 21, 2026.

DIVD reported the flaws to the Zammad project on September 24, 2026, opened case DIVD-2026-00015 on September 26, 2026 to scan for and notify other affected organizations, and published the two CVE records — CVE-2026-102489 and CVE-2026-102490 — on September 29, 2026 at 20:00 UTC. Both list DIVD case DIVD-2026-00015 and credit Merlon Security researchers Earth Grob, Luke Paris, Tijmen van der Spijk, Zohar Cochavi and Alje Woltjer as finders, alongside DIVD's own Mischa Rick van Geelen, Ralph Horn and Max van der Horst, with DIVD analysts Victor Pasman and Frank Breedijk credited on the analysis.

This is the kind of bug class a zero-day vulnerability describes by definition: both flaws were actively exploited before Zammad or the public had any way to patch against them.

The two vulnerabilities, explained

It's worth being precise here, because the two CVEs are distinct bugs that happen to combine into something much worse. Don't blur them together when deciding what to patch.

CVE-2026-102489 is a session-related flaw — CISA's KEV catalog labels it a "Session Fixation Vulnerability" — in Zammad's web application that an attacker can exploit without valid credentials (DIVD's own CVSS scoring marks Privileges Required as "NONE") to obtain remote code execution as the "zammad" service account. DIVD's advisory affects versions 6.3.0 up to 6.5.4, and notes the same underlying flaw is present in 7.0.0 through 7.1.3 as well, though DIVD states it is "not exploitable due to environment conditions" on those newer releases. Standalone, DIVD scores it CVSS 8.7 (HIGH); chained with the privilege-escalation bug below, that rises to 9.4 (CRITICAL).

CVE-2026-102490 is a completely separate, local privilege-escalation flaw: DIVD's advisory describes it simply as letting "the local zammad user escalate privileges to root." It is far more broadly present — DIVD's affected-version table lists essentially every release from 1.5.0 up through the 7.1.0-alpha pre-release on Linux and Docker deployments, with only installations predating 1.5.0 marked unaffected. Standalone, it scores 8.5 (HIGH); chained with CVE-2026-102489, it's the same 9.4 (CRITICAL) as above, since the two feed directly into each other.

How the chain works

Neither bug alone is "game over" in quite the same way the pair is together. CVE-2026-102489 gets an attacker code execution on the Zammad box, but only with the privileges of the low-privilege "zammad" service account — not root, and not necessarily full control of the underlying host. CVE-2026-102490 is the half that turns that limited foothold into a complete takeover: once you're running as the "zammad" user, by any means, it hands you root.

Chained, that's a path from an attacker with no valid account on the system to root on the server — which is why DIVD scores the combination at 9.4 CRITICAL for both CVE entries, well above either flaw's standalone score. Full root access on a ticketing system that routinely holds customer PII, support-ticket attachments, internal credentials and integration tokens is about as bad an outcome as a support-desk compromise gets, and it opens the door to follow-on attacks like data theft or deployment of ransomware across whatever network that server sits on.

Who's affected

If you self-host Zammad on Linux or in Docker, assume you need to act. DIVD's own tables put the practical exposure like this:

• Running Zammad 6.3.0 through 6.5.4: vulnerable to both CVEs, including the network-exploitable RCE half of the chain. Highest priority to patch.
• Running Zammad 7.0.0 through 7.1.3: carries the same underlying session flaw (CVE-2026-102489), but DIVD says it isn't currently exploitable there due to environmental protections in those builds — it still affects essentially the whole 1.5.0+ range for the privilege-escalation half (CVE-2026-102490), so an update is still warranted.
• Running anything from 1.5.0 up through the 7.1.0-alpha pre-release: in scope for CVE-2026-102490's local-to-root escalation on its own, independent of the RCE bug.
• Running a version older than 1.5.0, or already on 6.5.4+ / 7.1.4+: not affected by the respective flaw per DIVD's advisories.

Zammad's hosted SaaS offering is operated directly by Zammad GmbH rather than by individual customers, so the practical exposure here is squarely on organizations that self-host — exactly DIVD's own setup.

The AI-agent angle, and what DIVD actually said

The detail that's drawing the most attention is who — or what — broke in. DIVD published a separate case writeup, DIVD-2026-00014, "When, not if...", describing its own breach. In DIVD's own words, "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," and the organization states that "the modus operandi indicates an agentic AI powered attack, something we had not seen before."

DIVD's writeup points to specific behavior in the intrusion logs as the basis for that conclusion: it describes finding that "the agent justifies its own actions, explaining why what it's doing is okay and really not phishing" — something DIVD says a human attacker "wouldn't bother with" — and characterizes the overall operation as "loud and very messy, with the agent working automated and deciding each next step itself at speed on sloppy logic."

We're reporting that characterization as DIVD's own attribution, based on its published account of its own incident — not as an independently verified fact about the attacker's tooling. DIVD has not published the full forensic detail behind the "agentic AI" conclusion, and we have not seen primary evidence beyond DIVD's own case page. What is independently confirmed, via DIVD's and CISA's own records, is that the Zammad chain was exploited in the wild before the vendor or the public had patches available, and that it's now formally listed as exploited by CISA.

CISA adds both CVEs to its KEV catalog

On October 2, 2026, CISA added both vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog, listing the vendor/product as "Zammad GmbH | Zammad." CVE-2026-102489 is listed under the name "Session Fixation Vulnerability" and CVE-2026-102490 as "Improper Privilege Management Vulnerability," with CISA's entries noting the flaws can be chained together. Both carry a remediation due date of October 5, 2026, the standard short window CISA sets for vulnerabilities with confirmed active exploitation, and both require action under CISA's BOD 26-04 guidance, including forensic triage of potentially affected systems.

A KEV listing is a binding deadline for U.S. federal civilian agencies under Binding Operational Directive 22-01 (the directive that established the catalog), but it functions as a strong signal for everyone else, too: CISA only adds a CVE once it has evidence of active, in-the-wild exploitation, which is exactly what DIVD's own incident supplies here. This is one of several KEV additions this week affecting widely deployed enterprise software — see also our coverage of the FortiMail CVE-2026-104286 addition to the same catalog.

How to patch

The fix is straightforward and the same for both halves of the chain: upgrade to a version past the patched line DIVD's advisories mark as fixed.

• On the 6.x branch: upgrade to Zammad 6.5.4 or later.
• On the 7.x branch: upgrade to Zammad 7.1.4 or later.
• If you're running anything older than 6.3.0 on the 6.x line, or any pre-1.5.0 build, you predate the affected ranges for these two specific CVEs — but you're almost certainly out of support and carrying other unpatched issues, so update regardless.
• Check Zammad's own advisory history at zammad.com/en/advisories for the release notes tied to this fix. Zammad has also stated that, going forward, it will publish new advisories on GitHub Security Advisories rather than on its own site, so that's the place to watch for the next one.
• If you can't patch immediately, restrict network access to your Zammad instance to a VPN or trusted IP ranges, and review the privileges and sudo/setuid configuration available to the local "zammad" service account as a stopgap against the escalation half of the chain.

If you think you've already been compromised

Because CISA's KEV listing confirms active exploitation and DIVD's own case shows an intrusion moving from initial access to root "in seconds," patching alone may not be enough if you were already running a vulnerable version before September 29, 2026. CISA's BOD 26-04 guidance, referenced in both KEV entries, calls for forensic triage rather than a simple patch-and-move-on for affected systems. At minimum: rotate credentials and API tokens stored in or accessible to Zammad, review audit and access logs around and after September 21, 2026, for unfamiliar sessions or administrative actions, and check for new or modified admin accounts, webhooks, and outbound integrations before assuming the incident is contained.

What's next

Expect the Zammad advisory to be followed by more detail as DIVD's victim-notification case, DIVD-2026-00015, continues contacting organizations it identifies as exposed, and watch Zammad's GitHub security advisories for any follow-up fixes if edge cases in the patch surface. For IT teams, the immediate task list is short: confirm your Zammad version, upgrade to 6.5.4+ or 7.1.4+ today, and treat any pre-patch exposure window as a potential compromise worth investigating rather than a vulnerability that was merely "available" to attackers — DIVD's own experience is a reminder that for KEV-listed bugs, the gap between disclosure and exploitation can already be in the past by the time you read the advisory.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage