CVE-2026-102489 Google Chronicle · YARA-L

Detect Zammad Session Fixation Exploitation (CVE-2026-102489) in Google Chronicle

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.

MITRE ATT&CK

Tactic
Initial Access Persistence Credential Access

YARA-L Detection Query

Google Chronicle (YARA-L)
yaral 
rule zammad_session_fixation_cve_2026_102489 {
  meta:
    author = "Argus"
    description = "Zammad session cookie authenticated from multiple source IPs (CVE-2026-102489 session fixation)"
    cve = "CVE-2026-102489"
    severity = "HIGH"
  events:
    $e.metadata.event_type = "NETWORK_HTTP"
    re.capture($e.network.http.user_agent, ".*") = $ua
    $e.target.url = /\/(api\/v1\/signin|auth\/sessions|api\/v1\/sessions)/
    $e.network.http.response_code = 200
    $e.network.http.request.cookie = /_zammad_session/
    $e.principal.ip = $ip
    $cookie = $e.network.http.request.cookie
  match:
    $cookie over 10m
  condition:
    $e and #ip > 1
}
high severity medium confidence

YARA-L 2.0 rule that groups Zammad authenticated sign-in events by the session cookie value over a 10-minute window and fires when the same cookie is seen from more than one distinct source IP.

Data Sources

Web Server LogsReverse Proxy Logs

Required Tables

NETWORK_HTTP

False Positives & Tuning

  • Corporate NAT presenting one egress IP for many clients (inverse case).
  • Mobile network roaming within a session.
  • Authorized scanners replaying cookies.

Other platforms for CVE-2026-102489

Microsoft Sentinel (KQL) Splunk (SPL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) CrowdStrike LogScale (LogScale) All platforms (combined) →

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.

Last updated: 2026-10-03 Research depth: standard
References (5)

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

Related Techniques

[object Object][object Object][object Object]

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