A Zammad vulnerability chain was used on September 21, 2026 to break into the Dutch Institute for Vulnerability Disclosure (DIVD), and CISA added both CVEs to its Known Exploited Vulnerabilities catalog on October 2. Anyone running a self-hosted Zammad helpdesk should check its version today, and should know that the vendor and the researchers disagree on how far the second flaw reaches.
DIVD, a Dutch non-profit that normally scans for exposed systems and warns their owners, says the attack on its own ticketing server looked like the work of an autonomous AI agent.
| What happened | Two Zammad flaws, CVE-2026-102489 (session hijack to code execution) and CVE-2026-102490 (local privilege escalation to root), were exploited to breach DIVD |
| Who’s affected | Self-hosted Zammad. DIVD lists 6.3.0 to 6.5.4 as exploitable for the RCE, and the root flaw from v1.5.0 through v7.1.0-alpha |
| Severity | CVSS 9.4 for each, as reported by SecurityWeek and Security Affairs. We found no primary score from NVD or the vendor, and 9.4 is unusually high for a local flaw |
| Status | Both in CISA KEV since October 2, 2026. Zammad says 7.0 and later are not affected by CVE-2026-102489 and that it has not received details of CVE-2026-102490. No confirmed patch exists for the root flaw |
| What to do now | Upgrade to Zammad 7.2.0, run DIVD’s log check script, and take 6.x servers offline if you can’t upgrade |
What happened
DIVD’s case page for DIVD-2026-00015 sets out the timeline. Its Zammad server was breached on September 21. The team analyzed and reproduced the bugs over the next two days, reported them to Zammad on September 24, and on September 26 published a limited disclosure, scanned the internet for vulnerable instances and began notifying their owners.
According to SecurityWeek and Help Net Security, the intruder moved on to other services and took some data before network segmentation contained it. DIVD described the attacker as “loud and very very messy,” Help Net Security reports.
On October 2, 2026, CISA added both CVEs to the KEV catalog, labeling them a Zammad session fixation vulnerability and an improper privilege management vulnerability.
How the Zammad vulnerability chain works
The chain has two steps. CVE-2026-102489 lets an unauthenticated attacker hijack a session and run code on the server as the zammad service account. DIVD says releases 6.3.0 through 6.5.4 are exploitable, while 7.0.0 through 7.1.3 contain the bug but environment conditions stop it being exploited. CVE-2026-102490 then lifts that local zammad user to root.
Put together, someone on the internet goes from no account to full control of the host. DIVD says, as quoted by SecurityWeek, that the pair let the attacker do this “in seconds.” In our view, root on a helpdesk server is a strong pivot point: ticketing systems tend to hold mail credentials, integration tokens and years of customer conversations.
The vendor’s side
Zammad disputes parts of the disclosure. In a statement on its community forum, the company says it first received a report about CVE-2026-102489 in August 2026, that only 6.5 and earlier releases can actually be exploited, owing to the runtime environment they ship with, and that those releases are already out of support. Zammad still hardened the code, and the change ships in 7.2.0.
On CVE-2026-102490, Zammad says DIVD has given it no technical details, so it can’t confirm the flaw, its scope or the affected versions, and it has formally asked for them. DIVD’s case page, by contrast, says it reported the vulnerability to Zammad and that the vendor is working on a fix. Zammad also objects to the two-day gap between the report and public disclosure. We can’t resolve that disagreement from public material, so we’re treating the root flaw as real but unverified by the vendor.
Why it matters for small businesses
Zammad is an open-source helpdesk that organizations can run on their own servers. In our experience, that makes it a common pick for small support teams, agencies and nonprofits that want a helpdesk without per-seat SaaS fees, and those are often the installs nobody upgrades. That is the population exposed here: DIVD lists the RCE as exploitable on 6.3.0 to 6.5.4.
A compromised helpdesk is a data breach in its own right. For organizations handling EU residents’ data, GDPR Article 33 generally requires notifying the supervisory authority within 72 hours of becoming aware of a personal data breach. US firms should check their state breach-notification rules if customer personal data sat in tickets.
What to do now
- Find every Zammad instance you run, including test boxes, and record the version.
- If anything is on 6.x, upgrade to 7.2.0 today. If that can’t happen quickly, take the server off the internet, as DIVD recommends. Note that 7.2.0 hardens the code behind CVE-2026-102489; no patch has been confirmed for CVE-2026-102490, so keep exposure low even after upgrading.
- Download DIVD’s log check script from the case page and run it against your Zammad logs to look for its indicators of compromise.
- If the server was internet-facing on 6.3.0 to 6.5.4, assume compromise until proven otherwise. Isolate it, preserve logs and disk images, and rebuild on a clean host rather than cleaning in place, since an attacker with root can leave persistence behind. Then rotate the mailbox passwords, API tokens and integration secrets that Zammad stored, and review admin accounts.
- Put the helpdesk behind a VPN or an identity-aware proxy so the login page isn’t open to the world.
- Watch Zammad’s GitHub security advisories for a verified answer on CVE-2026-102490.
- Stop staff pasting passwords into tickets. A shared vault is the safer way to hand over credentials; our password manager comparison for small teams covers the options.
Oreaxe’s take
The AI angle will get the headlines, but the practical lesson is older: unsupported versions of self-hosted tools are where attacks land. If DIVD’s version ranges hold, an organization that had simply stayed on a supported Zammad release would have faced only the disputed root flaw, which needs a foothold first.
The disclosure fight matters too. When researcher and vendor disagree in public, admins are left to act on incomplete information. Our view is to act on the worst credible reading: upgrade, hunt in the logs, rotate secrets.
Finally, notice what DIVD says contained the damage: segmentation. A helpdesk server that can’t reach the rest of the network is, in our experience, a far more contained breach to clean up. Our small-business threat planning guide walks through how to do that on a small budget, and our recent FortiMail zero-day report shows the same patch-fast pressure on edge devices.
Sources
- DIVD CSIRT, DIVD-2026-00015: Vulnerabilities in Zammad, last modified October 1, 2026
- Zammad, Statement on vulnerability reports in DIVD case DIVD-2026-00015, October 2026
- CISA, CISA Adds Two Known Exploited Vulnerabilities to Catalog, October 2, 2026
- SecurityWeek, Zammad Zero-Days Exploited in AI-Powered DIVD Hack, October 1, 2026
- Help Net Security, AI agent used Zammad zero-days to breach Dutch vulnerability disclosure non-profit, October 1, 2026
- Security Affairs, U.S. CISA adds Zammad GmbH Zammad flaws to its Known Exploited Vulnerabilities catalog, October 2, 2026
- Zammad, zammad/zammad source repository, GitHub
- GDPR-Info, Article 33 GDPR: Notification of a personal data breach
Every factual claim links to its source. Spotted an error? Tell us.