Zammad CVE-2026-102489 and 102490: The Chain That Breached DIVD

On 2 October 2026 CISA added two vulnerabilities in the open source Zammad helpdesk to its Known Exploited Vulnerabilities catalog, both due 5 October. CVE-2026-102489 can lead to remote code execution as the zammad user. CVE-2026-102490 lets that user escalate to root. CISA's entries note the two can be chained.

The chain was used against the Dutch Institute for Vulnerability Disclosure itself. DIVD's case page records the breach on 21 September. DIVD told BleepingComputer the two flaws together let the attacker hijack sessions, run code and escalate to root "in seconds, due to the agentic part of this hack," and that network segmentation stopped the intruder from going deeper. DIVD then reported both issues to Zammad and began notifying owners of exposed instances.

What's affected

CVE-2026-102489 (session hijack or fixation leading to RCE as zammad):

• DIVD lists Zammad 6.3.0 to 6.5.4 as exploitable. It says the flaw also exists in 7.0.0 to 7.1.3 but is not exploitable there because of environment conditions.
• Zammad's statement says exploitation is only possible on 6.5 and older because of the runtime those versions use, and that 7.0 and later are not affected. It hardened the code anyway in 7.2.0.
• Zammad 6.5 and older are out of support and get no security fixes.

CVE-2026-102490 (local privilege escalation to root):

• GitHub advisory GHSA-p97w-927q-8vxq, published 8 October, rates it 8.5 under CVSS 4.0.
• Only installs from the DEB and RPM packages built with packager.io are affected. Installs from source and the official container images are not.
• All released packaged versions are affected. The fix is Zammad 7.2.2.

The root cause, per the advisory: service processes started as root and executed files owned and writable by the zammad account before dropping to that account, and the install directory was writable by it. Because the services restart automatically when they stop, an attacker with code execution as zammad could escalate within seconds with no admin action.

The disclosure was contested. DIVD's timeline shows a report to Zammad on 24 September and public scanning and limited disclosure on 26 September. Zammad said on 1 October it had not yet received technical details for CVE-2026-102490, and confirmed later that day that it had them. It also stated the LPE cannot be exploited remotely on its own.

How to check if you're exposed

Find out how Zammad was installed and which version runs:

# DEB or RPM package installs (the ones affected by CVE-2026-102490)
dpkg -s zammad 2>/dev/null | grep -i ^version
rpm -q zammad 2>/dev/null

# container installs
docker ps --format '{{.Image}}' | grep -i zammad

On package installs, check who owns the install directory and which user the services start as:

stat -c '%U %a %n' /opt/zammad
ps -eo user,pid,args | grep -i [z]ammad

For CVE-2026-102489, DIVD publishes a log check script, cve-2026-102489_ioc_check_script_v2.sh, that scans Zammad log files for indicators of compromise. Run it on every instance that was reachable from the internet, especially anything on 6.5 or older.

For signs of the root escalation, look for what an attacker does after getting root on a package install:

find /opt/zammad -newermt "2026-09-01" -user root -type f 2>/dev/null | head
find /etc/systemd/system /etc/cron* /root/.ssh -newermt "2026-09-01" 2>/dev/null

What to do now

1. Upgrade to Zammad 7.2.2 or later. That fixes the packaged LPE and includes the 7.2.0 hardening for CVE-2026-102489.
2. If you are on 6.5 or older, move to 7.2.2 now. DIVD's own advice was to upgrade to version 7 or take the instance offline.
3. Don't stop at 7.2.0. Zammad published several more advisories fixed in 7.2.1 on 6 October, including a critical multi factor authentication bypass through the email verification flow.
4. If DIVD's script or your own checks find indicators, treat the host as root compromised. Rebuild it, and rotate the database password, mail account credentials, API tokens and any LDAP or SSO secrets Zammad holds.
5. Keep the Zammad admin interface behind SSO or a VPN where you can. Helpdesk tools accept input from the public by design, which makes the rest of the surface worth shrinking.

Why it matters

A helpdesk holds customer conversations, attachments, and often credentials people pasted into tickets. It also tends to be internet facing and maintained less closely than core systems. That combination makes it an attractive way in, as DIVD's breach showed.

The packaging bug is the broader lesson. The application code was not the problem. Services started as root and then ran files the service account could change. Any package, container or systemd unit that drops privileges late has the same shape, and it turns every application RCE into a root RCE.

Try it yourself

On any Linux host running a packaged service, check whether the service account can write to files that run as root at startup:

SVC=zammad
find / -xdev -user "$SVC" -perm -u+w -type f 2>/dev/null | head
systemctl cat "$SVC"* 2>/dev/null | grep -E 'User=|ExecStart'

If a unit starts as root and executes something from that list, you have the same pattern. This demo shows how an incident and its postmortem get recorded and tracked:

Click through it at your own pace, or open it full screen.

Quick check

Sources

• DIVD-2026-00015: Vulnerabilities in Zammad
• GHSA-p97w-927q-8vxq: Local privilege escalation to root in DEB/RPM packages
• Zammad community: statement on CVE-2026-102489 and CVE-2026-102490
• Zammad security advisories on GitHub
• Zammad releases
• BleepingComputer: DIVD says Zammad zero-days enabled AI-driven network breach
• CISA Known Exploited Vulnerabilities Catalog