Zammad CVE-2026-102489 and CVE-2026-102490: exploited chain to root

Most helpdesk vulnerabilities expose tickets. This pair took an attacker from no account at all to root on the server. CVE-2026-102489 lets an unauthenticated request make Zammad 6.x disclose the session cookies of users who are logged in, and an administrator's session leads to code execution as the zammad service account. CVE-2026-102490 then turns that account into root on hosts installed from Zammad's DEB or RPM packages.

The first known victim was itself a vulnerability disclosure organization. The Dutch Institute for Vulnerability Disclosure (DIVD) says an attacker broke into its Zammad ticket system on 21 September 2026 using both flaws. It reported them to Zammad on 24 September, and the CVE records went public on 30 September. CISA added both to its Known Exploited Vulnerabilities catalog on 2 October with a 5 October deadline. Zammad fixed the root escalation in 7.2.2 on 8 October and shipped an emergency 6.5.5 for the session leak on 15 October.

Who is affected

The session leak needs only network access to the Zammad web interface. The root escalation needs a foothold as the zammad account first. Installs from source and the official container images are not affected by it, so a Docker install of 6.5 is exposed to the first bug but not the second.

The records disagree at the edges. CVE-2026-102489's description includes 6.5.4 but its formal range stops before it, and Zammad says only that 6.5 and earlier are exploitable. Early posts put the root flaw at 1.5 to 7.1.0-alpha; the CVE record and Zammad's GitHub advisory now say every packaged release before 7.2.2. Treat 6.5.4 and 7.2.1 as affected.

How the Zammad chain works

CVE-2026-102489: session cookies in an error response

CISA and NVD file this bug as session fixation (CWE-384). DIVD and the researchers at Horizon3 describe it differently: as a leak. Zammad's WebSocket server keeps connection data for every client, including the session cookie, and an error path returned that data to the requester. With a stolen administrator session, an attacker can run code as zammad.

Zammad says the runtime environment of 7.0 and later prevents exploitation. It hardened the affected code in 7.2.0 and hardened the WebSocket server code in 6.5.5. Horizon3 published a working exploit on 7 October.

CVE-2026-102490: root runs files the service account can change

Zammad's packages, built with packager.io, started service processes as root. Before switching to the zammad account, those processes ran files that zammad owned and could modify, and the installation directory was writable by that account too. The services restart automatically when they stop, so an attacker who controls the account can reach root within seconds, with no administrator involved.

Is it being exploited?

Yes. The public evidence comes from one victim and CISA:

• DIVD. Breached on 21 September 2026 through its Zammad instance and detected within 19 minutes; it investigated with Merlon Security. DIVD attributes the activity after root access to AI agents, citing the volume of artifacts and commented attack scripts. That attribution is its own assessment.
• CISA. Both CVEs were added to KEV on 2 October with a 5 October deadline and forensic triage required. Use in ransomware campaigns is listed as unknown.
• Public exploit. Horizon3's code covers CVE-2026-102489 only. It withheld details of the escalation.

We found no other named responder reporting exploitation. Two points are disputed. Zammad says it first received a report of the session issue in August 2026, when 6.5 was already out of support, so the "zero-day" label DIVD uses is contested for that bug. Zammad also objects that the root CVE went public before it received technical details, which arrived on 1 October. The two CVEs appear among the other October 2026 KEV additions.

Check your exposure

Find the install type and version, then search the logs for DIVD's indicator:

# Package installs: the root escalation applies to these
dpkg-query -W zammad 2>/dev/null || rpm -q zammad
 
# Docker Compose installs: the image tag is the version
docker compose images
 
# DIVD's indicator: session material in Zammad error output
zgrep -E 'ERROR -- :.*("Cookie"=>"|@clients=\{)' /var/log/zammad/*.log* /var/log/nginx/*.log*

For Docker installs, run the same pattern against the container logs. A hit means session cookies appeared in error output.

Fix it

Upgrade self-hosted installs to 7.2.2 or later. That covers both bugs: 7.x is not exploitable for the session leak, and 7.2.2 fixes the packaging flaw. Zammad's update guide says not to skip major versions, so a 6.5 install moves to 7.0 first and then to the latest release.

Package users may need to switch repositories before the update appears. Zammad now builds packages with a new toolchain, and the old repositories no longer receive updates. Its host upgrade and repository migration guide covers the switch, including the separate stable-6.5 channel that carries 6.5.5.

If you cannot leave 6.5 today, 6.5.5 closes the session leak only; Zammad also advises limiting server access to trusted administrators, and DIVD says to upgrade to version 7 or take the instance offline. Zammad SaaS customers need to do nothing.

Detect attempts and compromise

Published guidance is thin. What exists:

• Session material in errors. DIVD's script flags Zammad and nginx error lines that contain a cookie header value or the server's client registry. Any match means sessions were exposed, whether or not anyone used them.
• Unfamiliar processes and files. DIVD's script says a clean result is not the end of the check and asks you to look for processes and files you do not recognize on the host.

If any of these signals fired, assume the attacker had root and everything Zammad holds: tickets, mailboxes, channel credentials and API tokens. Rebuild the host rather than clean it, end every session, and rotate the credentials stored in Zammad.

Beyond this patch

DIVD was running an out-of-support release. Helpdesks hold mail, secrets and customer data, so they need the same support-lifecycle tracking as anything public, and a service account should never own code that root executes. After you patch, confirm the fix with evidence; how a retest verifies a fix explains the approach Rokkhe takes for findings it has reproduced.