CISA Gives Federal Agencies Three Days to Patch Two Zammad Flaws Being Exploited Now
Two critical bugs in the Zammad helpdesk platform can be chained for root-level takeover. CISA added both to the Known Exploited Vulnerabilities catalogue on 2 October 2026, with a patch deadline of 5 October.

Key points
- CISA added CVE-2026-102489 and CVE-2026-102490, two critical flaws in the Zammad helpdesk software, to its Known Exploited Vulnerabilities catalogue on 2 October 2026, giving federal civilian agencies until 5 October to patch.
- Both carry a CVSS severity score of 9.4 out of 10, and CISA says attackers are already using them in the wild.
- Chained together, the two bugs let an outside attacker hijack a user session, run code as the zammad service account, then climb to full root control of the server.
- The privilege escalation flaw is present in every current Zammad release, including the latest alpha.
- The order falls under Binding Operational Directive 26-04, which replaced the old blanket two-week patch window with a risk-tiered schedule for internet-facing systems.
The Cybersecurity and Infrastructure Security Agency has told federal civilian agencies they have three days to patch two actively exploited flaws in Zammad, a widely used open-source helpdesk platform.
Both bugs were added to the Known Exploited Vulnerabilities catalogue on 2 October 2026. Deadline: 5 October.
That's an unusually tight window. Most KEV entries carry a 21-day clock, so three days signals CISA believes what it's seeing is serious and spreading. We've tracked this pattern before: CISA handed federal agencies the same three-day window for a critical NetScaler flaw on 17 September.
What are the two flaws?
The pair are designed to be used together. On its own, each is bad. Chained, they hand an attacker the whole server.
CVE-2026-102489 is a session fixation weakness, meaning an attacker can trick the application into accepting a session identifier they already control, then ride that session once a legitimate user authenticates. The National Vulnerability Database entry links this to remote code execution running as the zammad user. SOURCE does not specify which version ranges are affected beyond the product name, so the table below reflects only what CISA has confirmed.
CVE-2026-102490 is an improper privilege management flaw. Anyone already running as the local zammad account can escalate to root, the highest level of control on a Linux server. CISA notes this one is present in all current versions, including the latest alpha.
Both sit at CVSS 9.4, which is critical.
| CVE | Flaw type | CVSS |
|---|---|---|
| CVE-2026-102489 | Session fixation leading to RCE as zammad user | 9.4 |
| CVE-2026-102490 | Local privilege escalation to root, all current versions | 9.4 |
Why does the three-day deadline matter?
Binding Operational Directive 26-04, titled Prioritizing Security Updates Based on Risk, governs how Federal Civilian Executive Branch agencies handle KEV entries. It prioritises rapid remediation of high-risk vulnerabilities on publicly exposed assets that grant total control after exploitation. The Zammad pair fits that description exactly: internet-facing ticketing systems chained to root.
BOD 26-04 also sets, in CISA's words, "basic expectations for when agencies must check whether threat actors compromised the system before the patch was applied." Patching isn't enough. Agencies running vulnerable Zammad instances are expected to look back for signs of prior intrusion.
Should you act if you're not a federal agency?
BOD 26-04 binds only FCEB agencies, but CISA's advisory urges every organisation running Zammad to treat the KEV listing the same way. Helpdesk platforms sit on the network edge, hold sensitive correspondence, and are often wired into email and single sign-on systems. That's a wide blast radius if the chain runs.
My read: the three-day deadline is the story. CISA doesn't spend that credibility often, and when it does the exploitation is usually broader than the catalogue entry admits. Anyone running a vulnerable Zammad instance should treat this as a live incident, not a patch ticket.



