CVE-2026-102489

Zammad Session Fixation Exploitation (CVE-2026-102489)

Initial Access Persistence Credential Access Last updated:

Detects exploitation attempts against CVE-2026-102489, a session fixation vulnerability (CWE-384) in Zammad (Zammad GmbH). An attacker can set or predict a victim's session identifier prior to authentication, and because Zammad fails to rotate the session token on successful login, the attacker-controlled session becomes authenticated once the victim logs in. This detection surfaces anomalous session-cookie behavior: session IDs supplied by the client that pre-date authentication, absence of session rotation across the login boundary, and reuse of a single session identifier across multiple distinct source IPs or user agents. CVE-2026-102489 is listed in the CISA KEV catalog (BOD 26-04) and is being actively exploited in the wild alongside the related CVE-2026-102490 local privilege escalation.

Vulnerability Intelligence

KEV — Known Exploited

Affected Software

Vendor
Zammad GmbH
Product
Zammad

Weakness (CWE)

CWE-384

Timeline

Disclosed
October 2, 2026

CVSS

Unscored
CVSS vector not yet published
Write-up coming soon

What is CVE-2026-102489 Zammad Session Fixation Exploitation (CVE-2026-102489)?

Zammad Session Fixation Exploitation (CVE-2026-102489) (CVE-2026-102489) maps to the Initial Access and Persistence and Credential Access tactics — the adversary is trying to get into your network in MITRE ATT&CK.

This page provides production-ready detection logic for Zammad Session Fixation Exploitation (CVE-2026-102489), covering the data sources and telemetry it touches: Web Server Logs, Reverse Proxy Logs, IIS Logs. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Initial Access Persistence Credential Access
Microsoft Sentinel / Defender
kusto 
let loginWindow = 10m;
let AuthEvents = W3CIISLog
| where csUriStem has_any ("/api/v1/signin", "/auth/sessions", "/api/v1/sessions")
| where scStatus in (200, 201, 302)
| extend SessionCookie = extract(@"_zammad_session[_a-z]*=([A-Za-z0-9%\-_.]+)", 1, tostring(csCookie))
| where isnotempty(SessionCookie)
| project TimeGenerated, cIP, csUserAgent, SessionCookie, csUriStem, csUsername;
AuthEvents
| summarize DistinctIPs = dcount(cIP), DistinctUAs = dcount(csUserAgent), IPs = make_set(cIP, 20), UAs = make_set(csUserAgent, 20), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), Users = make_set(csUsername, 20) by SessionCookie
| where DistinctIPs > 1 or DistinctUAs > 1
| extend SessionLifetime = LastSeen - FirstSeen
| where SessionLifetime < loginWindow or DistinctIPs > 1
| project FirstSeen, LastSeen, SessionCookie, DistinctIPs, DistinctUAs, IPs, UAs, Users
| order by DistinctIPs desc

Flags Zammad session identifiers (the _zammad_session cookie) reused across more than one source IP or user agent within a short window — the signature of a fixed session being handed to a victim and then authenticated. Requires IIS/reverse-proxy logs that capture the Cookie request header.

high severity medium confidence

Data Sources

Web Server Logs Reverse Proxy Logs IIS Logs

Required Tables

W3CIISLog

False Positives

  • Corporate NAT or egress proxy causing many users to share a single public IP while legitimately holding distinct sessions (inverse case; tune on cookie-to-IP cardinality).
  • Mobile users roaming between Wi-Fi and cellular networks mid-session, changing source IP legitimately.
  • Load testing or synthetic monitoring tools that replay a captured session cookie from multiple workers.

Sigma rule & cross-platform mapping

The detection logic for Zammad Session Fixation Exploitation (CVE-2026-102489) (CVE-2026-102489) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource: 

logsource:
  category: network_connection
  product: windows

Browse the community-maintained Sigma rules for this technique:

SigmaHQ rules for CVE-2026-102489 Sigma rules on detection.fyi

Platform-specific guides for CVE-2026-102489

Detect in Microsoft Sentinel (KQL) Detect in Splunk (SPL) Detect in Elastic Security (Elastic) Detect in IBM QRadar (QRadar) Detect in Sumo Logic CSE (Sumo) Detect in Google Chronicle (YARA-L) Detect in CrowdStrike LogScale (LogScale)
Last updated: 2026-10-03 Research depth: standard
References (5)

Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Session fixation via pre-set cookie against Zammad signin

    Expected signal: Reverse-proxy access log shows a /api/v1/signin POST bearing the client-supplied _zammad_session=fixed_sess_* cookie returning 200/201.

  2. Test 2Reuse fixated session from a second source

    Expected signal: Access log records authenticated requests carrying the same _zammad_session value from an IP distinct from the original login.

  3. Test 3Session cookie reused across differing user agents

    Expected signal: Two access-log entries share one _zammad_session value but differ in the User-Agent header.

Response Playbook

Triage

  1. Extract the flagged _zammad_session cookie value and build its full timeline: enumerate every request bearing it, noting the first appearance, the exact moment it became authenticated (first request with a valid user context), and all source IPs and user agents.
  2. Determine whether the session ID was presented by the client BEFORE authentication (session fixation signature) versus issued by the server at login. Compare the cookie value in the pre-login and post-login requests — if it is identical across the login boundary, Zammad failed to rotate the session and the fixation is confirmed.
  3. Identify the victim account tied to the authenticated session and the attacker-associated IP(s)/UA(s) that used the same cookie. Correlate the attacker IPs against the KEV/threat-intel feeds and prior alerts.
  4. Check for the chained CVE-2026-102490 local privilege escalation activity on the Zammad host following the hijacked login, since the two are reported as co-exploited.

Containment

  1. Immediately invalidate all active Zammad sessions (force a global session reset / rotate the session secret) and require re-authentication for all users.
  2. Block the attacker source IP(s) at the WAF/reverse proxy and revoke any API tokens created or used by the compromised account.
  3. Upgrade Zammad to the fixed release per the vendor advisory (https://zammad.com/en/product/releases/) and ensure session rotation on login is enforced; disable client-supplied session IDs.

Evidence Collection

  1. Preserve reverse-proxy/web-server access logs (including the Cookie header), Zammad Rails production logs, and the sessions table / Redis session store entries for the implicated cookie value.
  2. Capture the full request/response pairs for the pre-authentication and post-authentication requests sharing the session ID, plus any subsequent privileged actions taken under the hijacked session.

Escalation Criteria

  • ! Escalate to incident response if an administrator or agent account was authenticated via a fixated session, or if privileged configuration changes, user creation, or data export occurred under the hijacked session.
  • ! Escalate if evidence of the chained CVE-2026-102490 privilege escalation or any post-exploitation persistence is found on the Zammad host.

Investigation Guide

Forensic Artifacts

  • > Zammad session store entries (Redis/DB sessions table) showing a session ID whose created_at predates the associated user's login time.
  • > Reverse-proxy access logs showing the same _zammad_session cookie value across multiple source IPs or user agents.
  • > Zammad Rails production.log entries recording login events for the fixated session.

Tuning Guidance

Tune the source-IP cardinality threshold to your environment: if users sit behind a shared corporate NAT, pivot the logic to cookie-per-IP cardinality (one IP legitimately holds many distinct cookies) and alert instead on one cookie spanning IPs from different ASNs/geographies. Exclude known synthetic-monitoring and load-test source IPs. Lower noise by anchoring on the login boundary — only alert when the same cookie value is seen both before and after the authentication transition.

Hunting Queries

Baseline hunt for any Zammad session cookie that appears from more than one source IP, the core indicator of a shared/fixated session.

Hunting — KQL
kql 
W3CIISLog | where csUriStem has_any ("/api/v1/signin","/auth/sessions") | extend SessionCookie = extract(@"_zammad_session[_a-z]*=([A-Za-z0-9%\-_.]+)", 1, tostring(csCookie)) | where isnotempty(SessionCookie) | summarize dcount(cIP) by SessionCookie | where dcount_cIP > 1
Hunting — SPL
spl 
index=web uri_path IN ("/api/v1/signin","/auth/sessions") | rex field=cookie "_zammad_session[_a-z]*=(?<session_id>[A-Za-z0-9%\-_.]+)" | stats dc(src_ip) as ips by session_id | where ips>1

Atomic Red Team Tests

Test 1 Session fixation via pre-set cookie against Zammad signin
linux

In a lab, set a chosen session cookie, drive an authentication, and verify the cookie value is unchanged after login (no rotation), confirming the fixation primitive.

Command

bash 
FIX=fixed_sess_$(date +%s); curl -s -c /tmp/zj.txt -b "_zammad_session=$FIX" -X POST https://zammad.lab.local/api/v1/signin -H 'Content-Type: application/json' -d '{"username":"[email protected]","password":"LabPassw0rd!"}' -D - | grep -i set-cookie; echo "presented: $FIX"

Cleanup

bash 
rm -f /tmp/zj.txt

Expected Telemetry

Reverse-proxy access log shows a /api/v1/signin POST bearing the client-supplied _zammad_session=fixed_sess_* cookie returning 200/201.

Expected Detection

The KQL/SPL rule flags the fixed session cookie once it is subsequently used from a second source IP.

Test 2 Reuse fixated session from a second source
linux

Replay the fixated, now-authenticated session cookie from a different host/IP to simulate the attacker riding the victim's session.

Command

bash 
FIX=fixed_sess_replay; curl -s -b "_zammad_session=$FIX" https://zammad.lab.local/api/v1/users/me -H 'Accept: application/json' -o /dev/null -w '%{http_code}\n'

Cleanup

bash 
echo 'no local artifacts to clean'

Expected Telemetry

Access log records authenticated requests carrying the same _zammad_session value from an IP distinct from the original login.

Expected Detection

Detection fires on dcount(src_ip) > 1 for the shared session cookie.

Test 3 Session cookie reused across differing user agents
linux

Issue requests with the same fixated session cookie but two different User-Agent strings to simulate attacker/victim client divergence.

Command

bash 
C="_zammad_session=ua_div_sess"; curl -s -b "$C" -A 'Mozilla/5.0 (Windows NT 10.0)' https://zammad.lab.local/api/v1/users/me -o /dev/null; curl -s -b "$C" -A 'python-requests/2.31' https://zammad.lab.local/api/v1/users/me -o /dev/null; echo done

Cleanup

bash 
echo 'no local artifacts to clean'

Expected Telemetry

Two access-log entries share one _zammad_session value but differ in the User-Agent header.

Expected Detection

Detection fires on dcount(user_agent) > 1 for the shared session cookie.

Related Detections

Tactic Hubs

TA0001Initial AccessTA0003PersistenceTA0006Credential Access

Related Techniques

T1539Steal Web Session CookieT1078Valid AccountsT1557Adversary-in-the-Middle

Same Tactic: Initial Access

Popular Detections