Zammad Zero-Days CVE-2026-102489 and CVE-2026-102490: What Is Fixed and What Is Not

If you run Zammad, the helpdesk and ticketing system, check your version today. Anything on 6.5 or older is on a branch Zammad no longer patches and is the version range where the remote code execution flaw, CVE-2026-102489, can be used. Moving to Zammad 7.2.0, the version Zammad currently recommends, closes that path. It does not, on the evidence available as of October 5, 2026, settle the second flaw, CVE-2026-102490, which lets someone who already runs code as the zammad user become root.

This article separates what the CVE records, the discoverer, the vendor and CISA each say, because on this incident they do not fully agree.

What happened

The Dutch Institute for Vulnerability Disclosure (DIVD) is a non-profit made up largely of volunteer security researchers. It was breached. In its public timeline for the incident (case DIVD-2026-00014), DIVD dates the first malicious access to September 21, 2026 and says it became aware of the activity on September 22. On September 30 it said the attackers got in through two previously unknown flaws in Zammad, an open-source helpdesk it ran, which it then tracked as CVE-2026-102489 and CVE-2026-102490. On October 1 it said volunteer data had been taken, including email addresses and possibly contact details.

DIVD also says the intrusion was run by an automated AI agent that chose each next step itself, and that the agent moved from the Zammad user to root “in seconds”. That is DIVD’s own assessment from its forensic work with Merlon Security. We have not seen independent forensic evidence, and the trade press (Help Net Security) notes it is unknown whether this was part of a larger attack or a capability test. Treat the AI-agent description as DIVD’s account.

DIVD’s response gives a useful second detail. It says network segmentation and its incident team’s actions stopped the attackers from going deeper into its systems.

The two flaws

CVSS (Common Vulnerability Scoring System) is the standard 0 to 10 severity scale. These scores use version 4.0 and were assigned by DIVD, which also acted as the CVE Numbering Authority, the body that issued these CVE IDs.

Two details in secondary coverage are easy to get wrong. Some reports say both flaws score 9.4. In DIVD’s records, 9.4 is the score for the chain; each flaw alone scores lower. And one report describes an attack going “from unauthenticated access to root”. That is the chain, not a single flaw: the first needs no account, the second needs the foothold the first provides.

Where the sources disagree

Is there a fix? Help Net Security reported on October 1 that both flaws were “currently without a fix”. DIVD’s case file lists patch status as “Available” with the recommendation “Upgrade to Zammad version 7”. Zammad’s statement says CVE-2026-102489 does not affect current versions and that it hardened the code anyway in 7.2.0. These are not the same claim. The consistent reading is that 7.x removes the remote path for the first flaw, and no fix has been announced for the second.

Affected versions. The CVE record’s structured data lists CVE-2026-102489 as affected from 6.3.0 up to, but not including, 6.5.4. DIVD’s case file and the record’s own description say 6.3.0 to 6.5.4. A scanner that reads only the structured field could skip 6.5.4. Zammad’s wording is broader still: “6.5 and older”. Use Zammad’s range if you are deciding whether to act.

How the flaw was disclosed. DIVD’s case file says it reported the vulnerabilities to Zammad on September 24, 2026 and scanned for exposed instances and created a limited disclosure on September 26. Zammad says it first received a report about the session issue in August 2026, and that DIVD had not given it technical details of the second flaw until October 1. Zammad also wrote that it does “not consider this a responsible way to handle vulnerabilities”. We cannot reconcile the August report with DIVD’s September 24 date from the public record, so we state both. For readers the practical point is the same: the CVE IDs were public before the vendor had published fixes or an advisory for the second flaw.

How exploitable is the second flaw? DIVD’s case file says it affects “all versions”. Zammad said on October 1 that it “cannot be exploited remotely on its own. An attacker would already need access to your server.” Both can be true: it matters most as the second step of a chain, which is exactly how it was used.

What CISA says

CISA added both CVEs to its Known Exploited Vulnerabilities (KEV) catalog on October 2, 2026. The entries set a due date of October 5, 2026, mark forensic triage as required, and list ransomware campaign use as “Unknown”. CISA’s required action is to apply mitigations per vendor instructions or stop using the product if mitigations are unavailable. The due date comes from Binding Operational Directive 26-04 and applies to US Federal Civilian Executive Branch agencies, not to private organizations.

CISA’s own enrichment data on the CVE records rates exploitation as “active” and technical impact as “total” for both. It rates the first flaw “automatable: yes” and the second “automatable: no”, which fits the difference above: one can be launched against many servers over the network, the other needs a foothold.

One data point worth knowing, with its limits. The Exploit Prediction Scoring System (EPSS), a model that estimates the probability a CVE will be exploited in the next 30 days, gave CVE-2026-102489 a score of 0.0140 (about 1.4%, 71st percentile) and CVE-2026-102490 0.0063 (about 0.6%, 48th percentile) on October 4, 2026. Exploitation has already been confirmed for both. A low EPSS number soon after disclosure reflects how little public data the model had, not safety. Do not use it to lower priority for a flaw on CISA’s exploited list.

What to do, in order

This sequence is our recommendation, built on DIVD’s, Zammad’s and the Dutch NCSC’s published advice as cited. Vendor advice is marked as such.

1. Find every Zammad instance and its version

Include test, staging and forgotten copies. DIVD’s recommendation covers any version, and its affected range for the root escalation begins at 1.5.0. Record whether each one is reachable from the internet.

2. Preserve logs before you upgrade

The Dutch National Cyber Security Centre (NCSC-NL) advised copying application and network logs before updating, because they may help you check later for abuse of the second flaw, as reported by Help Net Security. Do this first. Our piece on logging for incidents rather than dashboards covers why off-server copies matter.

3. Remove the remote entry point

Zammad recommends moving to 7.2.0, released September 23, 2026 according to its release page. If you cannot upgrade today, DIVD’s alternative is to take the instance offline. Our addition: if the helpdesk must stay up for staff, restrict it to a VPN or an allowlist of source addresses until you have upgraded. If you are on 6.5 or older, treat the upgrade as overdue regardless of this incident, since Zammad says those versions get no security fixes.

4. Check for compromise, even after upgrading

DIVD published a log-check script for indicators of compromise, linked from its case file. We did not run it. Read any script before running it against production logs, and run it on a copy. A clean result lowers the likelihood of this specific activity. It does not prove a server was never accessed, and DIVD itself says it assumes breach until it can prove otherwise.

Upgrading after an intrusion does not remove an attacker who already has root. If the logs show suspicious sessions or code execution, plan a rebuild rather than a patch.

5. Assume the ticket system holds more than tickets

This part is analysis, not vendor guidance. A helpdesk typically stores customer emails and attachments, internal notes, and credentials for connected channels such as mailboxes and chat. If a server may have been reached, rotate those integration credentials and API tokens, and revoke active sessions. Our zero-day response guide covers the general order of work.

6. Watch for the second fix

Follow Zammad’s GitHub security advisories for CVE-2026-102490. When a fixed version is named, that becomes the target, not “version 7” in general.

The lesson that does not depend on Zammad

Two points from DIVD’s account apply to any internal tool, offered here as our reading of it.

• Low-severity entry points still matter when a second step exists. The first flaw lands on a service account with limited rights. The second turns that into root. Defenders who triage each CVE alone can underrate a chain. When two advisories name the same product on the same day, read them together.
• Segmentation is what limited the damage. DIVD credits it for stopping lateral movement. A ticketing server that can reach everything is a larger risk than the ticketing software itself.

The same pattern of an edge or internal service exploited before a full patch plan existed appeared in the FortiMail zero-day and the Citrix NetScaler zero-days in recent days, and the vulnerability backlog is where “exposed and exploited” should jump the queue.

Sources and verification

Checked on October 5, 2026. We did not test either vulnerability, run DIVD’s script or install Zammad. We could not open Zammad’s GitHub security advisories page or CISA’s website from our environment, so CISA data was read from CISA’s published KEV data file and from CISA’s entries embedded in the CVE records.

Vulnerability ManagementIncident Response