Detect Zammad Session Fixation Exploitation (CVE-2026-102489) in IBM QRadar
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
QRadar Detection Query
SELECT sourceip, "URL", "User Agent", "Cookie", username, COUNT(*) AS hits FROM events WHERE LOGSOURCETYPENAME(devicetype) ILIKE '%web%' AND "URL" ILIKE '%/api/v1/signin%' AND ("Cookie" ILIKE '%_zammad_session%') GROUP BY "Cookie" HAVING COUNT(DISTINCT sourceip) > 1 OR COUNT(DISTINCT "User Agent") > 1 ORDER BY hits DESC LAST 1 HOURSAggregates Zammad authentication events by the session cookie and flags any cookie observed from more than one source IP or user agent, the hallmark of a fixated session. Assumes a custom property extracts the Cookie header and URL.
Data Sources
Required Tables
False Positives & Tuning
- NAT gateways presenting many internal clients under one source IP.
- Mobile clients changing source IP during an active session.
- Authorized vulnerability scans replaying captured cookies.
Other platforms for CVE-2026-102489
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.
- 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.
- 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.
- 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.
References (5)
- https://nvd.nist.gov/vuln/detail/CVE-2026-102489
- https://zammad.com/en/product/releases/
- https://community.zammad.org/t/take-care-local-privilege-escalation-cve-2026-102490-is-reported-as-being-actively-exploited/21297/2
- https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk
- https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk
Response Playbook
Triage
- 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.
- 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.
- 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.
- 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
- Immediately invalidate all active Zammad sessions (force a global session reset / rotate the session secret) and require re-authentication for all users.
- Block the attacker source IP(s) at the WAF/reverse proxy and revoke any API tokens created or used by the compromised account.
- 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
- 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.
- 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
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.
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 > 1index=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>1Atomic Red Team Tests
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
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
rm -f /tmp/zj.txtExpected 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.
Replay the fixated, now-authenticated session cookie from a different host/IP to simulate the attacker riding the victim's session.
Command
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
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.
Issue requests with the same fixated session cookie but two different User-Agent strings to simulate attacker/victim client divergence.
Command
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 doneCleanup
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.