CISA KEV Alert: Zammad CVE-2026-102489 & CVE-2026-102490 — Session Fixation and Privilege Escalation Under Active Exploitation

On October 2, 2026, CISA added two vulnerabilities in Zammad GmbH's open-source ticketing and customer support platform to its Known Exploited Vulnerabilities (KEV) Catalog: CVE-2026-102489, a session fixation vulnerability, and CVE-2026-102490, an improper privilege management vulnerability. Inclusion in the KEV means one thing in practice: CISA has evidence these flaws are being actively exploited in the wild, and any organization running an internet-facing Zammad instance should treat this as a drop-everything patching event.

Under Binding Operational Directive (BOD) 26-04, Federal Civilian Executive Branch (FCEB) agencies are required to remediate KEV-listed vulnerabilities within mandated timelines. But make no mistake — the risk here extends far beyond the federal enterprise. Zammad is widely deployed by SMBs, MSPs, and enterprises as a helpdesk and ITSM platform. It is, by design, internet-accessible, holds sensitive customer communications, and typically integrates with email, LDAP/Active Directory, and internal notification systems. Compromising a Zammad instance gives an attacker a foothold inside your support workflow — where credentials, password reset links, and internal ticket intelligence flow freely.

Why This Pair of CVEs Matters Together

Individually, each flaw is serious. Chained, they represent a complete account-takeover-to-admin compromise:

• CVE-2026-102489 (Session Fixation) — The attacker forces or tricks a victim's browser into using an attacker-known session identifier. Once the victim authenticates, the attacker — who already knows the session ID — rides that authenticated session without ever needing the victim's credentials. This defeats password complexity and, in many implementations, bypasses MFA because the session is established after authentication succeeds.
• CVE-2026-102490 (Improper Privilege Management) — Once inside the application (using, for example, a fixated session), the attacker manipulates role or permission assignment logic to elevate from an unprivileged or low-privileged account (e.g., a customer portal user) to an agent or administrator role.

The realistic attack chain: attacker fixates a session for a victim user → victim logs in → attacker hijacks the authenticated session → attacker abuses the privilege management flaw to assign themselves the admin role → full control of the helpdesk, including the ability to exfiltrate ticket data, tamper with workflows, and harvest credentials submitted by users.

Technical Analysis

Affected Product

• Product: Zammad (open-source ticket system / customer support platform)
• Vendor: Zammad GmbH
• Exposure: Self-hosted instances are directly exposed, particularly those reachable from the internet. Zammad commonly sits behind Nginx/Apache reverse proxies on ports 443/3000 (Puma/Rails application server) with Elasticsearch and PostgreSQL backing stores.

Per CISA's KEV entry, organizations should consult the vendor advisory for the exact affected and fixed versions, apply the vendor-recommended update immediately, and if the product cannot be patched and no mitigation is available, CISA's standard KEV guidance applies: discontinue use of the product or isolate it from the network. Verify your running version with zammad run rails r 'puts Zammad::VERSION' or via the admin console footer.

CVE-2026-102489 — Session Fixation

Session fixation occurs when an application fails to rotate the session identifier upon authentication. A defender's mental model of the attack:

1. Attacker obtains a valid pre-authentication session ID from the application (or plants one via a crafted link, e.g., https://helpdesk.example.com/?session_id=attacker_controlled_value, or via a Set-Cookie injection through a related weakness).
2. Victim clicks the link and authenticates normally.
3. The application binds the victim's authenticated identity to the attacker-known session ID instead of issuing a fresh one.
4. Attacker presents the known session cookie and inherits the authenticated session.

Exploitation requirements: Victim interaction (clicking a link or using a pre-seeded session). No prior access needed. This maps to MITRE ATT&CK T1563 (Remote Service Session Hijacking) and T1185 (Browser Session Hijacking) at the application layer.

CVE-2026-102490 — Improper Privilege Management

Improper privilege management flaws allow a user to perform actions or assume roles beyond their authorization level. In a Rails-based application like Zammad, this class of bug typically manifests as mass-assignment or parameter pollution on user/role endpoints — e.g., submitting a request that includes role_ids or an admin flag in a profile-update or user-management API call that the server fails to properly authorize server-side. The net effect: an authenticated low-privilege user (such as a self-registered customer account) promotes themselves to agent or admin.

Exploitation requirements: Authenticated session at any privilege level — which CVE-2026-102489 conveniently provides. Maps to T1078 (Valid Accounts) and T1098 (Account Manipulation).

Exploitation Status

• CISA KEV: Confirmed active exploitation for both CVEs as of October 2, 2026.
• FCEB agencies must remediate per BOD 26-04 timelines. Private-sector organizations should adopt the same urgency — KEV inclusion is the single most reliable predictor of broad, opportunistic exploitation.

Detection & Response

Because Zammad is a web application, your highest-fidelity telemetry lives in reverse proxy / web server access logs (Nginx, Apache) and Zammad's own production logs — forward these to your SIEM via Syslog/CEF if you haven't already. The detections below focus on the observable behaviors of these two techniques rather than brittle payload signatures.

Key hunting hypotheses:

1. Session identifiers appearing in URL query strings (a fixation delivery indicator — legitimate sessions belong in cookies).
2. Multiple distinct source IPs or user agents sharing one session cookie (session theft/replay).
3. API calls to user/role management endpoints containing privilege parameters from customer-tier accounts.
4. Sudden role changes to admin in application logs, especially outside change windows.

---
title: Zammad Session Fixation - Session ID in URL Query String
id: 3b8f2c14-7d6a-4e51-b2c9-8f1a5d6e7c90
status: experimental
description: Detects session identifiers passed in URL query parameters to Zammad web endpoints, a hallmark of session fixation delivery (CVE-2026-102489). Legitimate Zammad sessions are cookie-based; session tokens in URLs indicate fixation attempts or phishing lures.
references:
  - https://www.cisa.gov/news-events/alerts/2026/10/02/cisa-adds-two-known-exploited-vulnerabilities-catalog
  - https://attack.mitre.org/techniques/T1563/
author: Security Arsenal
date: 2026/10/02
tags:
  - attack.credential_access
  - attack.t1563
logsource:
  category: webserver
  product: linux
detection:
  selection_uri_param:
    cs-uri-query|contains:
      - 'session_id='
      - 'sessionid='
      - '_session_id='
      - '_zammad_session'
  filter_known_good:
    cs-uri-stem|contains:
      - '/assets/'
      - '/favicon'
  condition: selection_uri_param and not filter_known_good
falsepositives:
  - Rare legacy integrations or monitoring tools passing session tokens via URL
level: high
---
title: Zammad Privilege Escalation via Role Parameter Injection
id: 9c1d4e57-2a83-4f60-b1d7-6e9c3a5f8024
status: experimental
description: Detects HTTP requests to Zammad user management API endpoints containing role or group assignment parameters, consistent with improper privilege management exploitation (CVE-2026-102490). Customer-tier accounts submitting role_ids or admin flags is anomalous.
references:
  - https://www.cisa.gov/news-events/alerts/2026/10/02/cisa-adds-two-known-exploited-vulnerabilities-catalog
  - https://attack.mitre.org/techniques/T1098/
author: Security Arsenal
date: 2026/10/02
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1098
  - attack.t1078
logsource:
  category: webserver
  product: linux
detection:
  selection_endpoint:
    cs-method:
      - 'POST'
      - 'PUT'
      - 'PATCH'
    cs-uri-stem|contains:
      - '/api/v1/users'
  selection_param:
    cs-uri-query|contains:
      - 'role_ids'
      - 'roles='
      - 'admin='
      - 'group_ids'
  condition: selection_endpoint and selection_param
falsepositives:
  - Legitimate admin user management via API integrations or provisioning scripts
level: high

// Hunt 1: Zammad session fixation indicators and session reuse anomalies
// Ingest Nginx/Apache access logs into CommonSecurityLog (CEF) or Syslog
let ZammadHosts = dynamic(["helpdesk", "support", "zammad", "ticket"]);
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where DestinationHostName has_any (ZammadHosts) or RequestURL has_any (ZammadHosts)
| where RequestURL has_any ("session_id=", "sessionid=", "_zammad_session")
   or (RequestMethod in~ ("POST","PUT","PATCH") and RequestURL has "/api/v1/users" and RequestURL has_any ("role_ids","admin=","group_ids"))
| project TimeGenerated, SourceIP, SourceUserAgent, RequestMethod, RequestURL, DestinationHostName
| order by TimeGenerated desc;

// Hunt 2: Same Zammad session cookie observed from multiple distinct source IPs (session replay)
Syslog
| where TimeGenerated > ago(7d)
| where SyslogMessage has_any ("zammad", "_session")
| extend SessionId = extract(@"_zammad_session=([A-Za-z0-9%+/=_-]+)", 1, SyslogMessage)
| extend SrcIP = extract(@"(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})", 1, SyslogMessage)
| where isnotempty(SessionId) and isnotempty(SrcIP)
| summarize DistinctIPs = dcount(SrcIP), IPs = make_set(SrcIP), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SessionId
| where DistinctIPs > 2
| order by DistinctIPs desc;

-- Hunt Zammad host: identify Zammad version, running processes, and recent admin role grants in logs
SELECT * FROM foreach(
  row={ SELECT Pid, Name, CommandLine, Exe, Username, CreateTime FROM pslist()
        WHERE Name =~ 'puma|ruby|rails|zammad|nginx' },
  query={
    SELECT Pid, Name, CommandLine, Username, CreateTime,
           read_file(filename='/opt/zammad/log/production.log', length=0) AS LogCheck
    FROM scope()
  })

-- Recent privilege-relevant lines in Zammad production log
SELECT FullPath, Mtime, Btime, Size
FROM glob(globs='/opt/zammad/log/production.log')
ORDER BY Mtime DESC

-- Established web connections from the Zammad app server (possible attacker callbacks)
SELECT Pid, Name, Status, Laddr, Raddr
FROM netstat()
WHERE Name =~ 'puma|ruby'
  AND Status = 'ESTABLISHED'
  AND Raddr.IP !~ '^(10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.|127\.)'

Run the production log review manually for role changes as well:

# Identify the installed Zammad version (compare against vendor fixed version)
zammad run rails r 'puts Zammad::VERSION' 2>/dev/null || grep -m1 -i version /opt/zammad/VERSION 2>/dev/null

# Hunt for admin role grants and suspicious user modifications in application logs
grep -iE "role.*admin|admin.*role|permission|updated.*User" /opt/zammad/log/production.log | tail -200

# Check reverse proxy logs for session IDs in URLs (fixation delivery)
grep -iE "(session_?id=|_zammad_session)" /var/log/nginx/access.log | tail -200

# List recent API writes to the users endpoint
grep -E "(PUT|PATCH|POST).*/api/v1/users" /var/log/nginx/access.log | tail -200

# Audit current admin accounts for unauthorized additions
zammad run rails r "User.with_permission('admin').each { |u| puts \"#{u.id} #{u.login} #{u.email} #{u.updated_at}\" }"

Remediation

1. Patch immediately. Apply the vendor-released fix per the official Zammad advisory referenced in the CISA KEV entries for CVE-2026-102489 and CVE-2026-102490. CISA's KEV due date applies to FCEB agencies under BOD 26-04; everyone else should treat this as a 24–72 hour emergency change window given confirmed active exploitation.
2. If you cannot patch today, take the instance off the internet. Place Zammad behind VPN/SSO-gated access, or at minimum restrict by source IP at the reverse proxy. CISA's standing guidance for unremediated KEV entries is to discontinue use — an unreachable instance is the pragmatic equivalent while you stage the update.
3. Invalidate all sessions after patching. Fixation attacks persist through stolen session tokens. Force a global logout: clear the Rails session store (e.g., flush the session cache/Redis keys or rotate the secret_key_base followed by an application restart) so every pre-patch session dies.
4. Audit for compromise before and after patching. Review admin role membership against your expected baseline, review user accounts created in the last 30 days, check for unfamiliar API tokens (zammad run rails r "Token.all.each { |t| puts t.inspect }"), and review outbound connections from the Zammad host for callbacks.
5. Rotate integrated credentials. Zammad typically holds credentials for inbound/outbound email (IMAP/SMTP), LDAP/AD bind accounts, and channel integrations (Slack, Teams, X/Twitter). Assume exposure; rotate all of them.
6. Harden going forward. Ensure Zammad sits behind a reverse proxy with modern TLS, disable public self-registration if not business-required, enforce MFA via upstream SSO (SAML/OIDC), and ship Nginx/Apache plus production.log to your SIEM so the detections above actually have telemetry to work with.
7. Verify and document. Confirm the fixed version post-update, record the remediation against both CVEs in your vulnerability management platform, and feed closure evidence into your BOD 26-04 (federal) or internal SLA reporting.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub