CVE-2026-102489: Zammad Session Hijacking Flaw Added to CISA KEV — Detection, Hunting, and Remediation Guide

When the U.S. Cybersecurity and Infrastructure Security Agency (CISA) adds a vulnerability to its Known Exploited Vulnerabilities (KEV) catalog, the message to defenders is unambiguous: threat actors are using this bug in the wild, and your exposure window is now measured in days, not months. This week, CISA added vulnerabilities affecting Zammad GmbH's Zammad — a widely deployed open-source helpdesk and customer support ticketing platform — to the KEV. The headline flaw, CVE-2026-102489, is a session hijacking vulnerability that can be chained into unauthenticated code execution on the underlying server.

That combination should get your attention. Helpdesk platforms sit at a uniquely dangerous intersection: they are internet-facing by design, they process untrusted user input from anyone who can open a ticket, and they hold a trove of sensitive data — customer PII, internal credentials pasted into tickets, password reset links, and integrations into mail systems, LDAP/Active Directory, and chatops tooling. An attacker who achieves code execution on a Zammad host isn't just inside a ticketing app — they've landed on a system with trusted connections into your identity and communications infrastructure.

This post breaks down what we know about the flaw, how to hunt for exploitation in your environment, and exactly what to do about it today.

Technical Analysis

What is affected

• Product: Zammad, the open-source web-based helpdesk/customer service platform developed by Zammad GmbH
• Deployment models at risk: Self-hosted Zammad instances — package installs (DEB/RPM), Docker/Compose deployments, and source installations. Zammad is a Ruby on Rails application typically fronted by nginx or Apache, backed by PostgreSQL or MySQL, and frequently integrated with Elasticsearch, Redis, and corporate LDAP/AD.
• Attack surface: Any Zammad instance reachable by an attacker — and because helpdesks must accept tickets from external customers, these portals are very commonly exposed directly to the internet.

The vulnerability: CVE-2026-102489

Per CISA's KEV entry and the reporting around it, CVE-2026-102489 is a session hijacking vulnerability in Zammad that can lead to unauthenticated remote code execution. From a defender's perspective, the attack chain looks like this:

1. Session compromise. The attacker obtains or forges a valid Zammad session without prior authentication — classically via session fixation, predictable/leaked session tokens, or improper session validation on the application side. No valid credentials are required.
2. Privilege assumption. With a hijacked session, the attacker operates within the application as a legitimate user. If the hijacked context belongs to an agent or administrator — or if the session handling flaw permits privilege escalation — the attacker gains access to administrative functionality.
3. Code execution. Zammad's administrative surface (schedulers, triggers, webhooks, integrations, and template rendering) provides pathways to execute attacker-controlled commands or code on the host as the zammad service account. Because no authentication is required to initiate the chain, this is a pre-auth RCE class issue — the worst-case profile for an internet-facing application.

Exploitation status

This is the critical point: CISA KEV inclusion means confirmed, active exploitation in the wild. The KEV catalog is not a list of theoretically severe bugs — it is reserved for vulnerabilities with evidence of real-world use by threat actors. If you run Zammad, assume scanning and exploitation attempts are already underway against your instance. Under Binding Operational Directive (BOD) 22-01, U.S. federal civilian agencies are required to remediate KEV entries by the due date listed in the catalog; every private-sector organization should treat that same deadline as their own minimum bar. Check the CISA KEV catalog for the current due date and the Zammad security advisories for the fixed versions applicable to your release train.

Why Zammad is an attractive target

I've responded to multiple incidents where the helpdesk was the initial access vector. Ticketing systems aggregate exactly what intruders want: customer communications (useful for downstream phishing), internal troubleshooting notes (which leak architecture details), password reset workflows, and integrations with email, Active Directory, and Slack/Teams. A compromised helpdesk is a springboard — expect attackers who land here to immediately enumerate integrations and harvest stored credentials for lateral movement.

Detection & Response

The detections below target the observable post-exploitation behavior of this attack chain: the web application process executing unexpected commands, suspicious session handling artifacts in web logs, and outbound connections from a server that should have a very predictable network profile.

Sigma Rules

---
title: Zammad Application Process Spawning Shell or Command Interpreter
id: 3b8f4a21-9c6d-4e17-b5a2-7f1c9d3e8042
status: experimental
description: Detects Zammad Ruby application processes (puma/rails/zammad workers) spawning shells or command execution tools, consistent with post-exploitation of CVE-2026-102489 unauthenticated code execution on a Zammad host.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog
  - https://securityaffairs.com/200248/security/u-s-cisa-adds-zammad-gmbh-zammad-flaws-to-its-known-exploited-vulnerabilities-catalog.html
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - 'zammad'
      - 'puma'
      - 'rails'
  selection_child_img:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/perl'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/base64'
  condition: selection_parent and selection_child_img
falsepositives:
  - Legitimate Zammad scheduler jobs invoking curl for webhook delivery (tune by webhook destination and parent worker name)
level: high
---
title: Suspicious Zammad Session Token Handling in Web Requests
id: 8d2e6f10-4a3b-4c95-91e7-2b6a0f5d1834
status: experimental
description: Detects web requests to Zammad containing session identifiers passed as URL parameters, a common artifact of session fixation/hijacking attempts such as exploitation of CVE-2026-102489. Session tokens should be transmitted via cookies, never in the query string.
references:
  - https://securityaffairs.com/200248/security/u-s-cisa-adds-zammad-gmbh-zammad-flaws-to-its-known-exploited-vulnerabilities-catalog.html
  - https://attack.mitre.org/techniques/T1563/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.initial_access
  - attack.credential_access
  - attack.t1563
logsource:
  category: webserver
detection:
  selection:
    cs-uri-query|contains:
      - '_session_id='
      - 'session_id='
      - 'session_token='
      - 'authenticity_token='
  filter_assets:
    cs-uri-stem|endswith:
      - '.css'
      - '.js'
      - '.png'
      - '.svg'
      - '.woff'
      - '.ico'
  condition: selection and not filter_assets
falsepositives:
  - Legacy API integrations passing tokens in query strings (identify and remediate the integration)
level: high

KQL — Microsoft Sentinel / Defender

This query hunts two signals together: (1) Zammad/Ruby application processes spawning shells or download tools on the host (via ingested Linux Syslog/audit data), and (2) the Zammad server making unexpected outbound connections visible in proxy or firewall logs (via CommonSecurityLog). A helpdesk server's outbound profile should be narrow — SMTP, package repos, Elasticsearch, and your IdP. Anything else is a lead.

let ZammadHosts = dynamic(["zammad-prod-01", "helpdesk.example.com"]); // replace with your Zammad hostnames/IPs
let Lookback = 14d;
let SuspiciousChildren = dynamic(["/bin/sh", "/bin/bash", "/bin/dash", "/usr/bin/curl", "/usr/bin/wget", "/usr/bin/nc", "/usr/bin/python3", "/usr/bin/base64"]);
let ProcHits =
    Syslog
    | where TimeGenerated > ago(Lookback)
    | where Computer in~ (ZammadHosts)
    | where SyslogMessage has_any ("zammad", "puma", "rails")
    | where SyslogMessage has_any (SuspiciousChildren)
    | project TimeGenerated, Computer, ProcessName, SyslogMessage;
let NetHits =
    CommonSecurityLog
    | where TimeGenerated > ago(Lookback)
    | where DeviceAction =~ "allowed" or DeviceAction =~ "accept"
    | where SourceHostName in~ (ZammadHosts) or SourceIP in~ (ZammadHosts)
    | where not(DestinationIP startswith "10." or DestinationIP startswith "192.168." or DestinationIP startswith "172.16.")
    | summarize Connections=count(), FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), Ports=make_set(DestinationPort) by SourceHostName, DestinationIP, DestinationPort
    | where Connections < 50; // rare, low-volume egress is the interesting kind
ProcHits
| union NetHits
| order by TimeGenerated desc;

Velociraptor VQL

Deploy this hunt across suspected Zammad servers to enumerate Ruby/Rails processes, their command lines, and their live network connections. Post-exploitation, you're looking for the zammad user running interpreters, shells, or holding outbound sockets to hosts outside your expected egress set.

-- Hunt Zammad hosts for suspicious Ruby app processes and their network connections
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime,
       netstat(Status='ESTABLISHED') AS Connections
FROM pslist()
WHERE Username =~ 'zammad'
   OR Exe =~ '(ruby|puma|rails)'
   OR CommandLine =~ 'zammad'

Follow up on any hit where a Ruby worker or the zammad user has spawned a child interpreter (sh, bash, python, perl) or holds an established connection to an unknown external IP. Also pull glob('/opt/zammad/log/production.log') and review it for requests immediately preceding the process anomaly — you're looking for the request that carried the hijacked session.

Remediation and Verification Script

Run this on your Zammad servers (tested for package-based DEB/RPM installs; adapt paths for Docker deployments, where you should instead pull the fixed image and recreate containers):

#!/bin/bash
# CVE-2026-102489 — Zammad KEV response: inventory, patch, invalidate sessions, verify
set -euo pipefail

# 1. Inventory the installed version and record it for change tracking
echo "=== Installed Zammad version ==="
(dpkg -l zammad 2>/dev/null || rpm -qa | grep -i zammad) | tee /root/zammad-version-before.txt

# 2. Backup database and config BEFORE upgrading (non-negotiable)
echo "=== Creating pre-patch backup ==="
su - zammad -s /bin/bash -c '/opt/zammad/contrib/backup/zammad_backup.sh' || \
  echo "[!] Backup script not found at default path — take a manual DB dump before proceeding"

# 3. Apply the vendor-fixed package (pulls from Zammad's official packagecloud repo)
echo "=== Updating Zammad package ==="
if command -v apt-get >/dev/null; then
  apt-get update && apt-get install --only-upgrade -y zammad
elif command -v dnf >/dev/null; then
  dnf update -y zammad
fi

# 4. Restart services so the patched code is actually running
echo "=== Restarting Zammad ==="
systemctl restart zammad
sleep 10
systemctl is-active zammad-web zammad-worker zammad-websocket && echo "[+] Services healthy"

# 5. Invalidate ALL existing sessions — a hijacked session survives a patch
# Redis-backed session/cache store:
if command -v redis-cli >/dev/null; then
  redis-cli -n 1 FLUSHDB 2>/dev/null && echo "[+] Redis session store flushed" || true
fi
# Force password/session reset for privileged accounts via Rails console:
su - zammad -s /bin/bash -c "cd /opt/zammad && rails r 'Setting.set(\"session_timeout\", 3600); puts \"[+] Session timeout hardened\"'"

# 6. Post-patch verification and compromise review
echo "=== Post-patch version ==="
(dpkg -l zammad 2>/dev/null || rpm -qa | grep -i zammad)
echo "=== Review: recent sessions and admin logins ==="
grep -iE "session|login|authenticated" /opt/zammad/log/production.log | tail -n 200 > /root/zammad-session-review.txt
echo "[+] Saved to /root/zammad-session-review.txt — review for sessions from unfamiliar source IPs"

# 7. Quick check: any zammad-owned shells or unexpected listeners?
echo "=== Anomalous processes owned by zammad user ==="
ps -u zammad -o pid,ppid,cmd | grep -E '(/bin/sh|/bin/bash|python|perl|nc |curl |wget )' || echo "[+] None found"

Remediation

Prioritize these steps in order — this is a KEV-listed, actively exploited flaw, so treat it as incident-adjacent, not routine patch work:

1. Patch immediately. Upgrade Zammad to the fixed release identified in the vendor's release notes at zammad.com/en/releases and in the Zammad GitHub security advisories. Package installs: apt-get install --only-upgrade zammad or dnf update zammad. Docker deployments: pull the latest patched image tag and recreate containers — do not assume a running container picked up a fix.
2. Invalidate every session. Patching closes the hole; it does not evict an attacker already holding a hijacked session. Flush the Redis-backed session/cache store and force re-authentication for all users — especially agents and administrators. Rotate any API tokens, webhook secrets, and integration credentials (SMTP, LDAP bind accounts, chat integrations) stored in Zammad.
3. Meet the KEV deadline. Federal civilian agencies are bound by the due date in the CISA KEV catalog. Everyone else: use it as your SLA. If you cannot patch by that date, take the instance offline or restrict it at the edge until you can.
4. Constrain exposure. A helpdesk needs to accept tickets from customers — it does not need its admin and agent interfaces exposed to the internet. Place agent/admin paths behind VPN, SSO with MFA, or IP allowlisting at the reverse proxy. This materially shrinks the blast radius of any session-handling flaw.
5. Hunt before you patch. Because exploitation is confirmed in the wild, assume you may already be compromised. Run the KQL and VQL hunts above across your Zammad infrastructure, review production.log for sessions originating from unfamiliar source IPs or with anomalous user agents, and check for persistence: new admin accounts, modified triggers/schedulers, unexpected webhooks, or cron entries owned by the zammad user.
6. Verify egress controls. The Zammad host should only be able to reach your mail server, package repositories, Elasticsearch, and identity provider. Anything else outbound should be blocked and alerted — it turns a reverse shell into a loud detection.
7. If you find evidence of exploitation, treat it as an IR event: image the host, preserve Rails and web server logs before rotation, and assume the data in the ticket system — including any credentials pasted into tickets — is compromised. Rotate accordingly.

Session hijacking flaws in internet-facing business applications are a favorite of both financially motivated groups and initial access brokers, precisely because they convert directly into pre-authenticated code execution on infrastructure that talks to everything else. Don't let your helpdesk become someone else's entry point.

Related Resources

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