Zammad CVE-2026-102489 & CVE-2026-102490: Session Fixation to Root Response Guide

Every other KEV-driven guide on this site so far has covered network-edge or security infrastructure — firewalls, VPN gateways, NAC, mail security. Zammad is a helpdesk/ticketing platform, which means it is easy to deprioritize in a patch queue behind 'real' security appliances. That instinct is wrong here: helpdesk platforms routinely hold customer PII, support-ticket attachments, and — critically — session tokens and credentials pasted into tickets by confused end users. A root-level compromise of a Zammad host is a data-exposure and lateral-movement incident, not a minor one, and CISA's KEV listing confirms attackers are already exploiting this chain in the wild.

Exposure depends on which Zammad release line is running and whether the deployment matches the 7.0–7.1 'not exploitable by default' carve-out — verify rather than assume the carve-out applies to your environment.

• •Inventory every Zammad instance and confirm the running version against the affected ranges: 6.3.0–6.5.4 (fully exploitable) and 7.0.0–7.1.3 (session-fixation present, RCE path environment-dependent — do not treat as safe without confirming your specific config)
• •Confirm the host's deployment model (Docker, package install, source) since CVE-2026-102490's local privilege-escalation path depends on how the zammad OS user's permissions and surrounding services are configured
• •Treat any Zammad instance reachable by customers or the public internet as the highest-priority target — session fixation requires only that a victim can be lured into using an attacker-supplied session ID, which is easiest against externally-facing support portals

With confirmed active exploitation and the federal KEV deadline already passed, treat this as an emergency patch rather than a scheduled upgrade.

• •Upgrade every affected instance to Zammad 7.2.0 or later — this is the only complete remediation for both CVEs
• •Until the upgrade is complete, force-invalidate all active sessions (rotate the session secret / restart the session store) to clear any already-fixated sessions
• •Review authentication logs for session IDs that were set before a login occurred, or for login activity from unexpected IP ranges immediately following a session being established — both are signatures of session fixation in progress
• •Audit the zammad OS user's sudo rights, file permissions, and any scheduled jobs or services it can influence, since CVE-2026-102490's escalation path runs through whatever privilege boundary separates that user from root on your specific install
• •Treat any host where exploitation is suspected as compromised at the root level, not just the application level — a root-RCE chain warrants full host rebuild under your IR plan, not just an application restart

CISA's October 5, 2026 deadline binds federal civilian agencies; it does not expire the risk for anyone else. A KEV entry with a deadline already in the past typically means active exploitation has had extra days to spread before most commercial organizations even hear about the chain — the response priority should be treated as higher, not lower, once a deadline has already elapsed. Organizations in regulated sectors should assess whether customer PII or credentials passed through a vulnerable Zammad instance during the exposure window and handle any confirmed access as a reportable incident under applicable breach-notification obligations (DPDP Act in India, sector-specific CERT-In timelines where applicable), independent of whether root compromise itself is confirmed.