Is CVE-2026-102489 (Zammad GmbH Zammad Session Fixation) being exploited in the wild?

Yes. CISA added CVE-2026-102489 to its Known Exploited Vulnerabilities catalogue on 2 October 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Zammad GmbH Zammad contains a session fixation vulnerability that can lead to remote code execution as the zammad user. Any organisation running the affected product should treat remediation as urgent.

What It Means When a Session Fixation CVE Is Being Actively Exploited

For a question like this, the practical issue is not the label alone, but what active exploitation changes for defenders. A session fixation flaw can let an attacker control or reuse a valid session context, which turns an authentication weakness into a post-login control problem. Once a CVE is in CISA’s KEV catalogue, it should be treated as a live exposure, not a theoretical defect.

When session handling is the weak point, the defender has to assume that login state, cookies, or session identifiers may be used as an access path rather than a mere convenience feature. That matters because session abuse often bypasses the normal “we patched it later” mindset: if exploitation has already begun, the question becomes whether anyone can still trust existing sessions, not just whether the software is fixed.

For current exploitation status, use the authoritative records, not secondary commentary. Confirm the item in the CISA Known Exploited Vulnerabilities Catalog and the underlying entry in the CVE Program or NIST National Vulnerability Database so your response is based on the canonical record.

What Remediation Should Prioritise First

The first priority is exposure confirmation: identify every internet-facing or internally reachable instance of the affected product, then determine whether those instances are actively used for administrative or privileged workflows. For a session-related flaw, usage context matters because the blast radius is usually higher where sessions are long-lived, broadly shared, or tied to privileged actions.

Remediation should then focus on the vendor fix or the vendor’s documented mitigation, followed by invalidating anything that may still be trusted from before remediation. That typically means expiring active sessions, reviewing authentication cookies or tokens that could have been fixed in place, and checking whether the product’s own session management state needs to be reset as part of the fix.

Use the FIRST EPSS score as a triage input if you need to compare this issue against other unfixed items, but do not let it override KEV status when active exploitation is already confirmed. KEV means the remediation queue should move from routine prioritisation to urgent action.

How To Check For Compromise Before and After Patching

With an exploited session weakness, compromise checks should look for signs of session abuse as well as direct application tampering. That includes unusual logins from unexpected source addresses, abrupt changes in session creation patterns, privileged actions performed by accounts that did not recently authenticate normally, and any evidence that the application started executing commands or behaving outside its normal workflow.

If patching must wait, reduce exposure immediately by tightening network access, restricting administrative reach, shortening session lifetimes where the product allows it, and monitoring for active session reuse. Where the product mediates access to sensitive operational data, preserve logs and authentication evidence before changing too much state, because that record may be the only reliable way to distinguish exploitation from normal user activity.

After remediation, assume that the trust boundary of the affected session layer may have been crossed. Re-authenticate users, force session renewal, and review whether any privileged accounts, API tokens, or automation credentials were reachable through the compromised application path. If evidence suggests deeper access, expand the investigation beyond the application itself into adjacent systems that may have accepted the same session or account trust.

Risk and Threat Considerations

Actively exploited session flaws are dangerous because they collapse the gap between authentication and code execution. When an attacker can fix or control a session and then pivot into application execution, the issue is no longer limited to account abuse, it becomes a path to system-level compromise and post-authentication persistence.

Failure mechanism: The attacker abuses session state to establish trusted access, then leverages that trust to reach privileged application functions or trigger remote code execution as the product user.

Impact: Existing logins may be untrustworthy, administrative workflows may be exposed, and the affected host may need full compromise assessment rather than simple patch verification.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation makes rapid identification and remediation of the vulnerable product essential.
Recommendation — Prioritise and remediate KEV-listed exposures immediately, then verify the vulnerable asset inventory.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The question is about an actively exploited CVE and how to confirm exposure and remediation.
	SI-2 — Flaw Remediation	A KEV-listed session-fixation flaw requires urgent fix application and post-fix validation.
	IA-5 — Authenticator Management	Session fixation can invalidate trust in active sessions and related authentication material.
Recommendation — Scan for the affected product, track exposure status, and verify remediation before closing the item. Apply the vendor fix or mitigation quickly and validate that the flaw is removed. Expire or replace potentially affected sessions and authentication material after remediation.
OWASP ASVS	V7 — Session Management	The vulnerability is specifically a session fixation issue, so session controls are central.
Recommendation — Review session creation, renewal, and invalidation behavior to prevent fixation abuse.

Practitioner Guidance

What to prioritise: Treat KEV listing as the trigger for immediate action, then validate whether the product is exposed in a way that makes active session abuse plausible. If it is reachable and user sessions are meaningful to operations, prioritise containment and session invalidation before broader hardening work.

What to verify: Confirm whether any currently valid sessions, API interactions, or admin workflows were established before remediation. If you cannot prove that trust state was clean, assume it was not and widen the investigation.

Practitioner takeaway: For an exploited session vulnerability, the real decision is not only whether the CVE is patched, but whether the environment can still trust any session created before remediation.