Skip to main content
Change Risk Intel
Cybersecurity

Zammad KEV: When Your Helpdesk Becomes the Breach Path

Ben Ennis Founder, Ennis Studio · former Partner Technology Advisor, ServiceNow · 13 min read

No affiliate links appear in this article. This is a defender’s and change board’s view of the Zammad advisories. It contains no exploit details.

Table of contents

Why this matters

On October 2, CISA added CVE-2026-102489 and CVE-2026-102490 to the Known Exploited Vulnerabilities catalog. Both affect Zammad, the open-source helpdesk and ticketing system, and both carried a due date of October 5. That’s a three-day clock that ran over a weekend. The KEV entries say the two flaws can be chained and flag both for CISA’s forensic triage requirements under BOD 26-04. They also tell agencies to “discontinue use of the product if mitigations are unavailable.”

Most KEV entries land on a firewall, a VPN, or a file-transfer appliance. This one landed on the system many IT teams use to record their changes, incidents, and approvals. When the helpdesk is the thing that got breached, the question is not only “are we patched?” It is also “can we still trust what our system of record says?”

The first known victim makes the point. The organization breached through these flaws was the Dutch Institute for Vulnerability Disclosure (DIVD), a nonprofit whose job is to find and report vulnerabilities. If an organization that scans the internet for exposed systems can be hit through its own ticketing platform, a typical enterprise helpdesk with a public customer portal is at least as exposed.

What happened at DIVD

DIVD has published its own account in case file DIVD-2026-00014. The timeline is short:

  • September 21: first access by a malicious actor on DIVD systems.
  • September 22: DIVD detected the activity, blocked access to all systems in its datacenter, and started a forensic investigation with Merlon Security.
  • September 24: DIVD reported the vulnerability to Zammad and said publicly that it had been hacked.
  • September 26: DIVD began scanning for exposed, vulnerable Zammad instances and notifying their owners under case DIVD-2026-00015.
  • October 1: DIVD said volunteer data had been exposed, including DIVD email addresses and possibly contact details.

DIVD wrote that “the modus operandi indicates an agentic AI powered attack, something we had not seen before.” It described the attack as loud and messy. The agent picked each next step on its own, at speed, and left overexplaining comments in its scripts that made reverse engineering easier. DIVD said the escalation from the Zammad user to root “happened in seconds.” It credited network segmentation and its response team with stopping the attacker from going deeper. DIVD has not linked the attack to any known threat actor, and we don’t either.

The defender’s lesson is speed, not novelty. A three-day KEV clock assumes a human attacker working through an environment over days. An automated chain that goes from session hijack to root in seconds shrinks the window between first access and lateral movement to almost nothing. That makes segmentation and fast detection worth more than a faster patch.

What the two CVEs are, and where the records disagree

The two CVEs do different jobs in the chain:

  • CVE-2026-102489 is a session fixation flaw (CWE-384). Per NVD, Zammad 6.3.0 through 6.5.4 are vulnerable to “a session hijack vulnerability that leads to remote code execution as the zammad user.” The same code exists in 7.0.0 through 7.1.3 but is “not exploitable due to environment conditions.”
  • CVE-2026-102490 is a local privilege escalation (CWE-269). NVD’s description reads: “All versions of Zammad including the latest alpha enable the local zammad user to escalate privileges to root.”

DIVD scores each flaw on its own and as a chain. On the CVE-2026-102489 page, the session flaw alone is CVSS 4.0 8.7 and the chain is 9.4. On the CVE-2026-102490 page, the privilege escalation alone is 8.5, with a local attack vector. That split matters for triage. On an instance already on 7.x, the remote entry point is not exploitable, and the remaining risk depends on who else can reach the server.

The vendor’s account is narrower. Zammad’s October 5 advisory says “Zammad 7.0 and later are not affected in practice” by CVE-2026-102489, and that Zammad 7.2.0 includes a hardening change to the affected code. On CVE-2026-102490, Zammad said information “was made public before we received the technical details necessary to reproduce and evaluate the issue.” It called the flaw a local escalation that “cannot be exploited remotely on its own,” and said its team was “working on a solution.” In an earlier community post, Zammad said: “We cannot confirm the vulnerability, its scope or the affected versions at this time.”

Even the affected range is not consistent. DIVD’s CVE-2026-102490 page lists affected versions as 1.5.0 up to, but not including, 7.1.0-alpha, while the description says “including the latest alpha.” Neither Zammad’s advisory nor the 7.2.1 release notes say that 7.2.1 fixes CVE-2026-102490. For a change board, that means the closure criterion can’t be “patched to a fixed version” for the escalation flaw. It has to be “upgraded to current stable, server access restricted, and compromise check completed.” Record that wording in the change.

What 7.2.1 tells you about the attack surface

Zammad shipped 7.2.1 on October 6 as “an important security update that addresses critical vulnerabilities.” Its release notes list 27 fixes, and the GitHub security advisories published the same day rate the MFA bypass as Critical. SaaS customers need no action, because Zammad says it already patched hosted instances.

We grouped the 27 fixes by what they put at risk in a system of record. The grouping is ours; the titles are Zammad’s.

Horizontal bar chart of the 27 fixes in Zammad 7.2.1, grouped by category: 15 authorization and data-scope leaks, 5 session and authentication issues, 4 stored XSS and HTML injection issues, 2 code execution and injection issues, and 1 case of stored channel credentials returned in clear text

CategoryCountExamples from the 7.2.1 listWhat it puts at risk
Authorization and data-scope leaks15Cross-organization ticket disclosure and takeover; ticket articles exposed without authorization; deactivated roles keeping accessConfidentiality of tickets, including change and incident records
Session and authentication5MFA bypass through the email verification flow; session identifier disclosed, enabling off-host takeover; inactive sessions still authorizedWho the system thinks approved or edited a record
Stored XSS and HTML injection4Stored XSS in autocomplete and tree select fields; clipboard HTML injectionAgent sessions and the integrity of what agents see
Code execution and injection2Remote code execution via template sanitizer bypass in automation configuration; second-order SQL injectionThe server, its database and its integrations
Credentials in clear text1Channel administration APIs returned stored channel credentialsMailbox and messaging accounts connected to the helpdesk

Two observations stand out. First, more than half of the fixes are about people seeing or touching records outside their permission scope. Second, the session and credential fixes go straight at attribution. If an attacker can take over a session or bypass MFA, an approval in the ticket history no longer proves who approved it.

Why a helpdesk compromise is a change-control problem

Your helpdesk is not just another app. For many teams it holds the change requests, the CAB approvals, the emergency-change justifications, and the incident timelines that auditors sample. Our guide to what SOC 2 auditors sample explains why those records carry so much weight. If the platform that stores them was compromised, you have three separate problems:

  1. Confidentiality. Tickets often contain configuration details, internal hostnames, and sometimes credentials that people paste in to get help faster.
  2. Integrity. An attacker with the Zammad user or root could, in principle, alter records. Zammad 7.2, released September 23, added a tamper-protected admin audit log whose entries “cannot be subsequently edited or deleted through either the user interface or the API,” per the Zammad 7.2 release page. That helps going forward, but it can’t vouch for records from before you upgraded. It also covers admin actions, not every ticket edit, and it requires an Elasticsearch reindex before it is fully available.
  3. Reach. Channel integrations connect the helpdesk to mailboxes and chat. The clear-text channel credential fix means those secrets may have been readable through the API before 7.2.1.

Zammad deserves credit for shipping 27 fixes quickly and for patching SaaS instances without customer action. The weakness is its support policy. The security page says fixes go to “the current stable version of Zammad only,” and the advisory confirms 6.5 and earlier “no longer receive security updates.” Teams that pinned an old version for stability have no patch path except a major upgrade. That turns a routine patch into a planned migration under a KEV deadline.

Running this as an emergency change

This is a textbook case for a pre-approved emergency path, like the one in our BOD 26-04 decision matrix. Exploitation is confirmed, the product is often internet-facing, and the vendor guidance is moving. Here is how we’d scope the change record:

  • Scope: every Zammad instance, including test copies and forgotten customer portals. DIVD found vulnerable instances by scanning the internet, so check your own external footprint against our live KEV tracker and asset inventory.
  • Implementation: upgrade to 7.2.1 (package or Docker), or take the instance offline, which is DIVD’s other recommendation. Restrict shell and server access to named administrators, as Zammad advises.
  • Verification: run DIVD’s log check script for indicators of compromise, linked from the DIVD-2026-00015 case page, and record the result in the change.
  • Contingency: if the check finds indicators, the change becomes an incident. Rotate channel credentials, API tokens and any secrets found in tickets, and preserve logs before rebuilding.
  • Residual risk: document that CVE-2026-102490 had no vendor-confirmed fix as of October 5. If you rely on access restriction as the control, log it in your compensating controls register with an owner and a review date.

More KEV-driven change guides are on our cybersecurity hub.

What to do about it

  1. Find every Zammad instance today. Include staging, demo, and customer-facing portals, and note the version and whether it is internet-facing.
  2. Upgrade self-hosted instances to 7.2.1. If an instance is on 6.5 or older, treat the upgrade as a major-version change with a tested backup and a rollback plan. Don’t stop at a minor patch that doesn’t exist.
  3. Restrict server access. Limit shell, SSH and container access to named administrators, and remove shared accounts on the host.
  4. Run the compromise check before closing the change. Use DIVD’s log check script. Treat any instance that was internet-facing on 6.3.0 through 6.5.4 since September 21 as a candidate for a full compromise assessment.
  5. Rotate what the helpdesk could reach. That means channel credentials for connected mailboxes and chat, API tokens, and any secrets found by searching ticket text.
  6. Protect your change evidence. Export recent change and CAB records to write-once storage. Enable the 7.2 admin audit log, and note in your audit file when it was turned on.
  7. Watch the vendor’s GitHub advisories. Zammad now publishes there, and the CVE-2026-102490 fix status may change after this article.

FAQ

Which Zammad versions are affected by CVE-2026-102489?

Per NVD, versions 6.3.0 through 6.5.4 are exploitable. The code is also present in 7.0.0 through 7.1.3 but is not exploitable because of the runtime environment those versions use. Zammad says 7.0 and later are not affected in practice.

Is there a fix for CVE-2026-102490?

As of Zammad’s October 5 advisory, the vendor had received technical details from DIVD and was working on a fix. Neither that advisory nor the 7.2.1 release notes say 7.2.1 fixes it. Upgrade to current stable, restrict server access, and check Zammad’s GitHub advisories for updates.

Do Zammad SaaS customers need to do anything?

Zammad says no action is required for SaaS customers because their instances were already patched. Review your own integrations anyway: credentials and tokens your hosted instance uses for email or chat channels are still worth rotating if you have any doubt.

Was the DIVD breach really carried out by an AI agent?

DIVD says the modus operandi “indicates an agentic AI powered attack,” based on notes in the attacker’s scripts and the speed of escalation. That is DIVD’s assessment from its own investigation. DIVD has not attributed the attack to a known actor.

What did CISA require for these KEV entries?

CISA set an October 5 due date and told agencies to apply vendor mitigations under BOD 26-04, follow its forensic triage requirements, and discontinue use of the product if mitigations are unavailable. Private-sector teams aren’t bound by the directive, but the deadline is a useful signal of urgency.

Why should a CAB care about a helpdesk vulnerability?

Because the helpdesk often stores the change records, approvals and incident timelines that prove your change process works. A compromise raises questions about confidentiality, about who really approved what, and about secrets stored in tickets. Fixing it is a change in its own right, and the evidence it produces needs protecting.

Sources

#zammad #cisa kev #helpdesk security #itsm #emergency change #bod 26-04 #audit evidence

Published October 7, 2026.