CISA KEV Adds Exploited Zammad Flaws: Upgrade to 7.2.0 and Hunt for Root Compromise

What CISA announced​

CISA's October 2 alert lists CVE-2026-102489 and CVE-2026-102490. Both are tied to Zammad GmbH's Zammad. CISA labels the first a Session Fixation Vulnerability and the second an Improper Privilege Management Vulnerability. The agency says it added them based on evidence of active exploitation.

The alert also points to Binding Operational Directive (BOD) 26-04. That directive covers Federal Civilian Executive Branch agencies, and CISA says it applies only to them. CISA still encourages every organization to adopt risk-based vulnerability management and to prioritize KEV entries.

The directive was issued on June 10, 2026. According to CISA's bulletin, it ranks remediation by four factors:

• asset exposure
• KEV status
• exploit automation
• post-exploitation technical impact

The same bulletin says agencies must check in designated scenarios whether an adversary compromised an asset before the patch was applied.

What the researchers found​

The Dutch Institute for Vulnerability Disclosure (DIVD) tracks the issue as case DIVD-2026-00015. Its case page says it found the two CVEs while investigating a separate incident. The timeline runs as follows:

• September 21: the vulnerability was used to breach DIVD.
• September 22–23: DIVD analyzed and reproduced it.
• September 24: DIVD reported it to Zammad.
• September 26: DIVD scanned for exposed instances and began notifying owners.

DIVD describes the two flaws this way:

• CVE-2026-102489: a session hijack that leads to remote code execution as the zammad service user. DIVD lists Zammad 6.3.0 through 6.5.4 as affected. It says 7.0.0 through 7.1.3 also contain the flaw but aren't exploitable because of environment conditions.
• CVE-2026-102490: a local privilege escalation that lets the local zammad user become root. DIVD lists versions 1.5.0 through 7.1.0-alpha as affected.

DIVD's CVE page rates CVE-2026-102489 at 8.7 (High) alone and 9.4 (Critical) when chained with CVE-2026-102490. It lists the flaw as network-reachable, low complexity, needing no privileges, and automatable.

Together the two flaws make a full chain. A remote attacker gets code execution as the Zammad account, then escalates to root. DIVD reported the attackers used the second flaw to reach root and then accessed other services. Media coverage, including SecurityWeek, says the intrusion looked like an automated, AI-driven attack. That characterization comes from DIVD's account and its repetition in press reports. I haven't verified it independently.

Where the vendor disagrees​

Zammad's October 1 community statement partly disputes DIVD's findings. I couldn't retrieve that page directly, so this is based on the research notes. Zammad says:

• CVE-2026-102489 is exploitable only on Zammad 6.5 and older. It says 7.0 and later are not affected, though it hardened the code in 7.2.0.
• It has not received technical details for CVE-2026-102490. It therefore cannot verify the claim, its scope or the affected versions.
• It recommends updating to 7.2.0, and updating immediately if you run 6.5 or older. It also says versions 6.5 and older no longer receive security fixes.

"Not affected" and "present but not exploitable here" are not the same claim. Zammad's position on the second flaw is that it can't confirm it, not that it has disproved it.

Some outlets reported that upgrading to version 7 doesn't fix the privilege escalation. For example, Tech Times said upgrading to version 7 does not patch CVE-2026-102490. That reflects the state of play when those reports were written. Zammad's later statement points to 7.2.0 as the release to move to. Check the vendor's current advisory for the exact fixed versions.

What administrators should do​

1. Inventory. Find every Zammad instance, its version, and whether it is reachable from the internet.
2. Upgrade. DIVD recommends moving to Zammad 7 or taking the system offline. Zammad specifically recommends 7.2.0. Don't wait for the vendor and researcher to settle their disagreement.
3. Preserve logs first. NCSC-NL advises copying application and network logs before installing the update. The logs could help confirm later whether the system was attacked.
4. Hunt for compromise. DIVD offers a log-check script that looks for its indicators of compromise in Zammad logfiles. A clean result from a limited check doesn't prove the system was never breached. Upgrading doesn't remove an attacker's existing access either.
5. Assume root-level exposure if compromise is suspected. Isolate the host and investigate. Review credentials, API tokens and connected services that the Zammad server could reach.

Why this matters beyond Zammad​

Two things stand out for anyone managing IT:

• KEV status is a prioritization signal. Under BOD 26-04's logic, an internet-facing asset with a KEV-listed, automatable flaw that gives full control belongs at the top of the queue. That's good guidance for any organization.
• Vendor and researcher disagreements shouldn't delay action. Disclosure disputes about version ranges are common, and the safe approach is to patch to the newest supported release while the argument plays out.

For Windows-centric shops, ticketing systems often hold credentials, screenshots, remote-support details and asset data. A compromised help desk server can become a pivot point into Active Directory-joined environments. Treat it like any other internet-facing server.