Zammad root privilege escalation flaw added to CISA KEV (CVE-2026-102490)
At a glance
| Severity | CRITICAL |
|---|---|
| CVSS | CVE-2026-102490: 9.4 |
| EPSS (30-day exploit probability) | CVE-2026-102490: 0.6% |
| In CISA KEV (exploited) | Yes, due 2026-10-05 |
| Vendor | Zammad GmbH |
| CVE IDs | CVE-2026-102490 |
CISA added a root privilege escalation flaw in the Zammad help desk platform, tracked as CVE-2026-102490, to its Known Exploited Vulnerabilities (KEV) catalog on 2 October 2026. Federal agencies must act by 5 October, and the CVSS 4.0 score of 9.4 makes this a priority for anyone running a self-hosted Zammad server.
What happened
CISA classifies the bug as an improper privilege management vulnerability. According to the NVD description, the local zammad service user on a host running Zammad can escalate its privileges to root. Because that account is the one the application runs as, any other way of getting code to run in the application’s context could be turned into full control of the underlying server.
CISA’s entry notes that this vulnerability can be chained with CVE-2026-102489, another Zammad flaw that was added to the catalog around the same time. The public details do not describe how the chain works, who is exploiting it, or how many systems are affected. The NVD record was published on 30 September 2026, and its references point to a write-up from the DIVD CSIRT (DIVD-2026-00015).
Why this matters for defenders: a local privilege escalation is often underestimated because it needs a foothold first. In practice, help desk platforms process content from outside users, so a foothold is a realistic starting point. Once an attacker is root, they can read application data, change logs, install persistence and move to other systems that the server can reach. Treat the host as fully compromised if you find evidence of exploitation, and rebuild it from a known good state instead of cleaning it in place.
Am I affected?
The NVD description says all versions of Zammad, including the latest alpha, are affected. The structured data lists these entries:
- Zammad versions from 1.5.0 up to, but not including, 7.1.0
- Zammad 7.1.0
No fixed version is named in the information available to us, so check the vendor’s advisory and the DIVD write-up for the current status before assuming a release closes the issue. Any Zammad installation you run on your own Linux host should be treated as in scope until you have confirmed otherwise.
Technical details
- Weakness: CWE-269, improper privilege management.
- Severity: CVSS 4.0 base score 9.4 (critical). The vector shows network attackability with low complexity, no privileges required and user interaction needed (passive), with high impact on confidentiality, integrity and availability.
- Exploitation: listed in CISA KEV, which means CISA has evidence of exploitation. Use in ransomware campaigns is recorded as “Unknown”.
- KEV dates: added 2 October 2026, remediation due 5 October 2026.
- EPSS: 0.00629, a low modelled probability of exploitation. The KEV listing is stronger evidence than this score, so do not use the EPSS value to deprioritise the fix.
CISA’s required action is to apply mitigations in line with the vendor’s instructions and its BOD 26-04 guidance, including the forensics triage requirements it references, or to stop using the product if mitigations are not available.
What to do
- Inventory every Zammad instance you operate, including test and internal systems, and note its version and whether it is reachable from the internet.
- Follow the vendor’s mitigation instructions as soon as possible. CISA’s deadline for federal agencies is 5 October 2026, and other organisations should use it as a guide.
- Also check for and address CVE-2026-102489, since CISA says the two flaws can be chained.
- Because exploitation has been reported, review hosts for signs of compromise: unexpected root-owned processes started by the
zammaduser, new accounts, scheduled tasks or SSH keys, and unusual outbound connections. Follow the forensics triage steps referenced in the CISA entry. - If you cannot mitigate, restrict access to the Zammad server to trusted networks, or take it offline, as CISA suggests discontinuing use where mitigations are unavailable.
- Tell your incident response team and the owners of the help desk service, which usually holds sensitive customer and employee data.
We will update this article if more detail on the exploitation or a fixed version is published.
