Zammad session fixation flaw CVE-2026-102489 exploited, CISA KEV
At a glance
| Severity | CRITICAL |
|---|---|
| CVSS | CVE-2026-102489: 9.4 |
| EPSS (30-day exploit probability) | CVE-2026-102489: 1.4% |
| In CISA KEV (exploited) | Yes, due 2026-10-05 |
| Vendor | Zammad GmbH |
| CVE IDs | CVE-2026-102489 |
CISA added a Zammad session fixation flaw, CVE-2026-102489, to its Known Exploited Vulnerabilities (KEV) catalog on 2 October 2026, which confirms it is being exploited in the wild. The Zammad vulnerability can lead to remote code execution as the zammad user, carries a CVSS score of 9.4, and has a federal remediation due date of 5 October 2026.
CISA also notes the flaw can be chained with CVE-2026-102490, another Zammad entry in the same catalog. If you run a self-hosted Zammad help desk, treat this as a same-day task.
What happened
Zammad is a ticketing and help desk platform. CVE-2026-102489 is a session fixation weakness (CWE-384): an attacker can take over a user session, and that hijack leads to remote code execution on the server under the zammad service account.
CISA lists the vulnerability as “Zammad GmbH Zammad Session Fixation Vulnerability” and added it on 2 October 2026. The NVD record was published on 30 September 2026. Whether the flaw is used in ransomware campaigns is listed as unknown. Details of the attacks seen so far, such as who is exploiting it or how many victims there are, have not been disclosed in the data we reviewed.
Am I affected? Zammad versions
The NVD record lists these affected ranges:
- Zammad >= 6.3.0 and < 6.5.4
- Zammad >= 7.0.0 and <= 7.1.3
The sources do not fully agree on the details. The NVD description says versions 6.3.0 to 6.5.4 are vulnerable, while the structured list says below 6.5.4, so the boundary at 6.5.4 is unclear. The description also says the 7.0.0 to 7.1.3 releases contain the flaw but are “not exploitable due to environment conditions”, yet the structured list still counts them as affected. Fixed version numbers are not given in the data we have. Check the vendor advisory for the exact patched releases rather than relying on a version boundary here.
Technical details
- Weakness: CWE-384, session fixation.
- Severity: CVSS 4.0 base score 9.4 (critical). The vector shows network access, low complexity, no privileges and no attack requirements, but user interaction is required (passive).
- Impact: remote code execution as the zammad user.
- Exploitation: CISA KEV, added 2 October 2026, due date 5 October 2026.
- EPSS: 0.01396, about 1.4%. This is a statistical estimate of exploitation likelihood and it is low here, but confirmed exploitation in KEV outweighs it.
- Chaining: CISA says it can be combined with CVE-2026-102490.
Why this matters
Analysis, not new facts. Help desk systems hold customer data, internal conversations and often password reset emails or attachments. Code execution on that server gives an attacker a foothold with access to all of it, and the service account may reach databases and integrations. Because the flaw needs a user to take part in the session, expect phishing-style delivery where an agent or customer is lured to a crafted link.
Anything in CISA KEV should be patched or mitigated within hours, not in the next maintenance window. The three-day deadline here is unusually short, which signals real urgency for internet-facing instances.
What to do: fix Zammad CVE-2026-102489
- Identify every Zammad instance, including test and cloud-hosted ones, and note its version.
- Apply the vendor’s mitigations or update following the Zammad advisory. CISA’s required action is to apply vendor mitigations, follow BOD 26-04, and discontinue use of the product if no mitigation is available.
- Also address CVE-2026-102490, since the two can be chained.
- Invalidate active sessions after updating, so any hijacked session cannot be reused. This is a precaution drawn from the nature of the flaw, not a vendor instruction.
- Restrict access to the Zammad web interface where possible, for example behind a VPN or an allow list, until patching is verified.
Detection and hunting ideas
No indicators of compromise have been published. These ideas follow from the facts and are suggestions only:
- Review web server and application logs since at least 30 September for unusual or repeated session creation, and for one session ID used from several IP addresses.
- Look for child processes spawned by the Zammad application user, such as shells or download tools, and for unexpected outbound connections from the server.
- CISA’s required action references forensic triage requirements. If you find signs of compromise, preserve evidence before rebuilding the host.
Tell your help desk team and security contacts about the deadline, and record the decision and patch date for audit purposes.
