CVE-2026-102490: Zammad Privilege Escalation to Root Actively Exploited — Detection and Remediation Guide

On October 2, 2026, CISA added CVE-2026-102490 to the Known Exploited Vulnerabilities (KEV) catalog, confirming what defenders feared: this is not a theoretical bug. Zammad — the open-source, Rails-based ticketing and helpdesk platform used by thousands of organizations — contains an improper privilege management vulnerability that allows the local zammad service account to escalate privileges to root on the underlying host. Worse, CISA's entry explicitly notes this flaw can be chained with CVE-2026-102489, which means an attacker who gains code execution in the Zammad application context can convert a service-level foothold into full root control of the server.

If you run Zammad on-premises — particularly internet-facing instances handling customer tickets, attachments, and inbound email parsing — treat this as an emergency change window. KEV inclusion means exploitation is happening in the wild right now, and helpdesk platforms are high-value targets: they sit at the intersection of customer data, credentials embedded in tickets, and internal communication workflows.

Technical Analysis

Affected Product

• Vendor/Product: Zammad GmbH Zammad (self-hosted deployments on Linux — DEB/RPM packages, source installs, and Docker-based deployments where the container runs the zammad user)
• Vulnerability class: Improper Privilege Management (CWE-269)
• Impact: Local privilege escalation from the zammad service account to root
• Chaining: Can be combined with CVE-2026-102489 — the companion flaw that provides the initial code execution in the Zammad user context — to achieve unauthenticated-or-low-barrier remote-to-root compromise

Why This Matters: The Two-Stage Chain

In my experience leading IR engagements against compromised Rails applications, the pattern is depressingly consistent: an application-layer flaw gives the attacker code execution as the service account, and a local privilege management weakness — a misconfigured sudoers entry, a writable root-owned script the service can invoke, an overly permissive file capability, or a helper binary that trusts service-account-controlled input — closes the gap to root. That is exactly the attack shape CISA is describing here.

Stage one (CVE-2026-102489) lands the attacker inside the Zammad process context. Stage two (CVE-2026-102490) abuses the improper privilege management condition to escape the service account. Once root, expect the standard post-exploitation playbook: persistence via systemd units or cron, credential harvesting from the Zammad database (config/database.yml holds DB credentials in plaintext), web shells dropped into the Rails public/ directory, and lateral movement using the host's trusted position — helpdesk servers commonly hold SMTP credentials, LDAP bind accounts, and ticketing integrations with internal systems.

Exploitation Status

• CISA KEV: Added 2026-10-02 — confirmed active exploitation
• Federal mandate: Federal Civilian Executive Branch agencies must remediate per the KEV due date and in alignment with BOD 26-04 (Prioritizing Security Updates Based on Risk) and CISA's Forensics Triage Requirements — meaning evidence preservation before remediation where compromise is suspected. Private-sector organizations should treat the KEV deadline as their own.
• Required action per CISA: Apply vendor mitigations; if mitigations are unavailable, follow applicable BOD 26-04 cloud guidance or discontinue use of the product.

Detection & Response

Because exploitation requires the attacker to operate as the zammad user before escalating, your highest-fidelity detections focus on two behaviors: (1) the zammad user invoking privilege-elevation mechanisms or shells, and (2) the Zammad/Rails process spawning unexpected child processes. Zammad under normal operation spawns ruby, bundle, rails, sidekiq-style workers, and database clients — it should essentially never spawn sudo, su, bash -i, curl|bash pipelines, or binaries running with UID 0 whose parent is the application.

Deploy these rules to any Linux host running Zammad, and ensure auditd/Sysmon-for-Linux or equivalent process telemetry is flowing to your SIEM.

---
title: Zammad Service Account Privilege Escalation Attempt
id: 8f2a1b34-6c7d-4e59-9a01-2b3c4d5e6f70
status: experimental
description: Detects the local zammad service account invoking privilege escalation utilities or interactive shells, consistent with exploitation of CVE-2026-102490 (improper privilege management allowing zammad user to escalate to root).
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-102490
  - https://attack.mitre.org/techniques/T1548/
author: Security Arsenal
date: 2026/10/02
tags:
  - attack.privilege_escalation
  - attack.t1548
  - attack.t1068
logsource:
  category: process_creation
  product: linux
detection:
  selection_user:
    User|contains: 'zammad'
  selection_img:
    Image|endswith:
      - '/sudo'
      - '/su'
      - '/doas'
      - '/pkexec'
      - '/bash'
      - '/sh'
      - '/dash'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/perl'
  condition: all of selection_*
falsepositives:
  - Rare administrative maintenance performed interactively as the zammad user; investigate any hit
level: high
---
title: Zammad Rails Process Spawning Suspicious Child Process
id: 3c9d5e17-2f48-4b6a-8d12-7e8f9a0b1c2d
status: experimental
description: Detects Zammad application processes (ruby/bundle/rails) spawning shells, downloaders, or system utilities, indicating initial code execution that may precede CVE-2026-102490 privilege escalation chained with CVE-2026-102489.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-102490
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/10/02
tags:
  - attack.execution
  - attack.t1059
  - attack.privilege_escalation
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith:
      - '/ruby'
      - '/bundle'
      - '/rails'
      - '/puma'
      - '/sidekiq'
  selection_child:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/socat'
      - '/base64'
      - '/chmod'
      - '/chown'
      - '/sudo'
  filter_reindex:
    CommandLine|contains:
      - 'bundle exec'
      - 'rails runner'
  condition: all of selection_* and not 1 of filter_*
falsepositives:
  - Zammad background jobs invoking system utilities for ticket processing; tune per environment
level: high
---
title: UID Zero Process With Zammad Ancestry
id: 61b4c8a2-5d93-4e71-af26-9c0d1e2f3a4b
status: experimental
description: Detects a root-owned process spawned from the Zammad application tree, the end state of successful CVE-2026-102490 exploitation. High fidelity - zammad processes should never fork root children.
references:
  - https://www.cisa.gov/known-exploited-vulnerabilities-catalog?search_api_fulltext=CVE-2026-102490
  - https://attack.mitre.org/techniques/T1068/
author: Security Arsenal
date: 2026/10/02
tags:
  - attack.privilege_escalation
  - attack.t1068
logsource:
  category: process_creation
  product: linux
detection:
  selection:
    User: 'root'
    ParentUser|contains: 'zammad'
  condition: selection
falsepositives:
  - Package post-install scripts during apt/rpm upgrades executed via dpkg hooks; correlate with package manager logs
level: critical

For Microsoft Sentinel environments ingesting Linux syslog and auditd via the AMA connector or CEF, this hunt query surfaces zammad-account privilege transitions and suspicious process lineage:

// Hunt for zammad user privilege escalation and suspicious child processes (CVE-2026-102490)
let timeframe = 14d;
let SuspiciousImages = dynamic(["/sudo","/su","/doas","/pkexec","/bash","/sh","/dash","/curl","/wget","/nc","/ncat","/socat","/python3","/perl","/base64"]);
Syslog
| where TimeGenerated > ago(timeframe)
| where Computer has_any ("zammad") or ProcessName has_any ("ruby","bundle","rails","puma","sidekiq","sudo","su")
| where SyslogMessage has_any ("zammad","sudo","su:")
| extend PrivEsc = iff(SyslogMessage has_any ("COMMAND=","session opened for user root"), "PrivilegeTransition", "AppActivity")
| project TimeGenerated, Computer, ProcessName, SyslogMessage, PrivEsc, HostIP
| order by TimeGenerated desc;
// Correlate auditd execve events for zammad-UID processes spawning elevation tools
union isfuzzy=true
(Syslog
| where TimeGenerated > ago(timeframe)
| where SyslogMessage has "EXECVE" or SyslogMessage has "type=SYSCALL"
| where SyslogMessage has "zammad" or SyslogMessage has_any (SuspiciousImages)
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| order by TimeGenerated desc)

For live-response triage with Velociraptor, hunt across your Linux fleet for root processes parented to Zammad application processes and for shells running under the zammad account:

-- CVE-2026-102490 triage: find root processes spawned from Zammad app processes
-- and any interactive shells / elevation tools under the zammad account
LET parents = SELECT Pid, Name, Username
FROM pslist()
WHERE Name =~ 'ruby|bundle|rails|puma|sidekiq'
   OR Username =~ 'zammad'

SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Ppid in (SELECT Pid FROM parents)
  AND (Username =~ 'root'
       OR Name =~ 'sudo|su|doas|pkexec|bash|sh|dash|curl|wget|nc|socat|python|perl')

If any of these fire, assume compromise: isolate the host, preserve memory and disk before patching (consistent with CISA's Forensics Triage Requirements referenced in the KEV entry), and pull the Zammad Rails logs (log/production.log), web server access logs, and the zammad user's shell history.

The following Bash script audits a Zammad host for exposure indicators and hardens the service account while you schedule the vendor update:

#!/bin/bash
# CVE-2026-102490 exposure audit & interim hardening for Zammad hosts
# Run as root. Does NOT replace vendor patching.

echo "=== [1] Zammad version and install method ==="
if command -v dpkg >/dev/null 2>&1; then dpkg -l | grep -i zammad; fi
if command -v rpm  >/dev/null 2>&1; then rpm -qa | grep -i zammad; fi
[ -d /opt/zammad ] && cat /opt/zammad/VERSION 2>/dev/null

echo "=== [2] zammad account shell (should be nologin for service use) ==="
getent passwd zammad

echo "=== [3] Sudo/suid exposure for zammad user ==="
grep -rE '^[^#]*zammad' /etc/sudoers /etc/sudoers.d/ 2>/dev/null
sudo -l -U zammad 2>/dev/null

echo "=== [4] World-writable files owned by root under Zammad paths ==="
find /opt/zammad -maxdepth 4 -perm -o+w -user root 2>/dev/null | head -50

echo "=== [5] Suspicious recent shells/elevation by zammad user (auditd) ==="
ausearch -ui $(id -u zammad 2>/dev/null) -x sudo -ts recent 2>/dev/null | tail -40
ausearch -ui $(id -u zammad 2>/dev/null) -x bash -ts recent 2>/dev/null | tail -40

echo "=== [6] Recently modified files in Rails public dir (web shell check) ==="
find /opt/zammad/public -type f -mtime -14 2>/dev/null

echo "=== [7] Persistence check: cron and systemd units referencing zammad paths ==="
crontab -l -u zammad 2>/dev/null
grep -ril zammad /etc/cron* /etc/systemd/system/ 2>/dev/null | grep -vi 'zammad.service\|zammad-web\|zammad-worker\|zammad-websocket'

echo "=== [8] INTERIM HARDENING: lock zammad login shell ==="
usermod -s /usr/sbin/nologin zammad && echo "zammad shell set to nologin"

echo "=== [9] INTERIM HARDENING: strip any sudo rights for zammad ==="
grep -rlE '^[^#]*zammad' /etc/sudoers /etc/sudoers.d/ 2>/dev/null | while read -r f; do
  cp "$f" "$f.bak-cve-2026-102490"
  sed -i '/zammad/s/^/# CVE-2026-102490-mitigation: /' "$f"
  echo "Commented zammad entries in $f (backup: $f.bak-cve-2026-102490)"
done
visudo -c && echo "sudoers syntax OK"

echo "=== DONE. Review output, then apply the vendor patch immediately. ==="

Remediation

1. Patch immediately. Apply the Zammad update per the vendor's security advisory for CVE-2026-102490 and the chained CVE-2026-102489. Check the official Zammad release notes and security advisories at zammad.com and the Zammad GitHub repository for the fixed package versions, and monitor the CISA KEV entry for updated guidance. Verify package versions post-upgrade with dpkg -l | grep zammad or rpm -qa | grep zammad.
2. Respect the KEV deadline. Federal agencies are bound by the KEV due date and BOD 26-04; private organizations should adopt the same date as an internal SLA. If you cannot patch within that window, CISA's required action is explicit: discontinue use of the product until mitigations are applied.
3. Forensics before patching if you suspect compromise. Per CISA's Forensics Triage Requirements cited in the KEV entry, capture volatile data, disk images, and logs from potentially affected hosts before remediation wipes evidence. A patched host with no forensic review is a host where you may have evicted the attacker's tooling but not their access.
4. Harden the service account. The zammad user should have a nologin shell, zero sudoers entries, and no write access to root-owned files or scripts it can invoke. Audit file capabilities (getcap -r / 2>/dev/null) and SUID binaries reachable from the service context.
5. Reduce blast radius. Place Zammad behind a reverse proxy with strict TLS and access controls, restrict inbound management ports, and network-segment the host from domain controllers, mail servers, and databases it doesn't directly need. Rotate all credentials stored in or accessible from the Zammad host — database passwords, SMTP/LDAP bind credentials, API tokens in ticket integrations — after any suspected exposure.
6. Hunt retroactively. Run the detections above over at least the past 30 days of telemetry. KEV additions typically lag initial exploitation; assume the window of exposure predates October 2, 2026.

If your team lacks the capacity for a retrospective hunt or forensic triage of your helpdesk infrastructure, that's precisely the engagement profile our IR and managed detection teams handle.

Related Resources

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