CVE-2026-102490 Splunk · SPL

Detect Zammad Improper Privilege Management Local Privilege Escalation (CVE-2026-102490) in Splunk

Detects exploitation and exposure of CVE-2026-102490, an actively-exploited (CISA KEV) improper privilege management (CWE-269) vulnerability in Zammad GmbH's Zammad help desk / ticketing platform. The flaw allows a lower-privileged local or authenticated actor to escalate privileges within the Zammad application context, obtaining agent or admin-level capabilities they were not granted. This detection surfaces vulnerable Zammad deployments, anomalous privilege/role changes in Zammad audit logs, and local escalation artifacts on hosts running the Zammad service (typically Ruby/Rails under a dedicated 'zammad' service account backed by Elasticsearch and PostgreSQL).

MITRE ATT&CK

Tactic
Privilege Escalation

SPL Detection Query

Splunk (SPL)
spl 
index=linux (sourcetype=linux_secure OR sourcetype=syslog OR sourcetype="zammad:production")
(process_name=ruby OR process_name=rails OR process_name=rake OR host="zammad*" OR source="*zammad*production.log")
("permission" OR "role" OR "Users::Permission" OR "user.roles" OR "admin" OR "privilege")
| rex field=_raw "(?i)user[_ ]?id[=:]\s*(?<target_user>\d+)"
| rex field=_raw "(?i)(?<action>grant|add|assign)\s+.{0,20}(?<grant_target>admin|role|permission)"
| stats count min(_time) as firstTime max(_time) as lastTime values(action) as actions values(grant_target) as targets by host, process_name, target_user
| where count > 0
| convert ctime(firstTime) ctime(lastTime)
| sort - lastTime
high severity medium confidence

Splunk correlation over Zammad host syslog and the Zammad production.log for permission/role grant events indicative of CVE-2026-102490 exploitation.

Data Sources

Linux syslogZammad production.logauditd

Required Sourcetypes

linux_securesyslogzammad:production

False Positives & Tuning

  • Sanctioned admin role assignment during agent onboarding.
  • Scheduled identity-provider sync reconciling roles in Zammad.
  • Package upgrade or rails migration run under the zammad service account during a change window.

Other platforms for CVE-2026-102490

Microsoft Sentinel (KQL) Elastic Security (Elastic) IBM QRadar (QRadar) Sumo Logic CSE (Sumo) Google Chronicle (YARA-L) 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 1Zammad role escalation via rails console (lab)

    Expected signal: Zammad production.log and PostgreSQL history entry recording a role change to Admin for the target user; process telemetry for the ruby/rails rake invocation under the zammad account.

  2. Test 2Direct permission grant to low-privileged user (lab)

    Expected signal: production.log 'Users::Permission' / permission grant entry and corresponding history row.

  3. Test 3Suspicious zammad-account process referencing permissions (lab)

    Expected signal: ProcessRollup2 / auditbeat process event: ruby/rails executed by user 'zammad' with command line containing 'Permission' and 'admin'.

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

Response Playbook

Triage

  1. Confirm the affected host is running Zammad and identify the installed version (`zammad run rails r 'puts Version.get'` or check the package version); compare against the fixed release listed at https://zammad.com/en/product/releases/.
  2. Review the Zammad activity/audit log (Admin > System > Monitoring, or the `history` table in PostgreSQL) for recent role or permission changes — specifically any user granted the Admin or Agent role without a corresponding authorized admin action.
  3. Correlate the timestamp of any suspicious privilege change with web access logs and session data to identify the source user_id, IP address, and session that triggered the escalation.
  4. Determine whether the escalating account was a newly created or previously low-privileged (customer) account, which strongly indicates exploitation rather than legitimate administration.

Containment

  1. Isolate or restrict external access to the Zammad instance (block at reverse proxy / WAF) until the patch is applied, as this vulnerability is on the CISA KEV list and actively exploited.
  2. Revoke elevated roles from any account that was escalated without authorization and force a password reset plus session invalidation (`zammad run rails r 'Setting.set(...)'` / delete sessions) for affected and admin accounts.
  3. Apply the vendor-fixed Zammad release immediately per CISA BOD 26-04 prioritization guidance; schedule an emergency change if outside normal windows.

Evidence Collection

  1. Preserve the Zammad `production.log`, the PostgreSQL `history` and `users`/`roles`/`permissions` tables, and reverse-proxy access logs covering the suspected exploitation window.
  2. Capture the current role/permission assignments for all accounts (`zammad run rails r 'User.all.each{|u| puts "#{u.login}: #{u.roles.pluck(:name)}"}'`) as a baseline snapshot and export the OS-level auditd log for the zammad service account.

Escalation Criteria

  • !Escalate to incident response if any customer-tier or newly registered account obtained Admin/Agent privileges, or if privileged actions (ticket data export, user impersonation, config change) followed the escalation.
  • !Escalate to management and legal/compliance if evidence shows data access or exfiltration via the escalated account, given KEV status and potential breach-notification obligations.

Investigation Guide

Related Techniques

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

Forensic Artifacts

  • >Zammad `production.log` entries showing permission/role assignment
  • >PostgreSQL `history` table rows recording role grants
  • >Reverse-proxy/web access logs for the exploiting session
  • >auditd records for the zammad service account
  • >Zammad session records in the database

Tuning Guidance

Baseline which accounts and automation (LDAP/SAML sync, onboarding workflows) legitimately modify Zammad roles, and whitelist those user_ids/source IPs. Narrow the regex to the exact log signature emitted by your Zammad version's permission-change code path once observed. Focus alerting on escalations where the target account was previously a customer or was created within the last 24 hours, which dramatically reduces false positives from routine administration.

Hunting Queries

Surface all Zammad role/permission grant activity over the past week to baseline normal admin behavior and spot anomalous escalations.

Hunting — KQL
kql 
Syslog | where TimeGenerated > ago(7d) | where SyslogMessage has "zammad" and SyslogMessage has_any ("Admin","role","permission") | where SyslogMessage matches regex @"(?i)(grant|assign|add).{0,30}(admin|role)" | project TimeGenerated, Computer, SyslogMessage
Hunting — SPL
spl 
index=linux (source="*zammad*production.log" OR sourcetype=syslog host="zammad*") ("role" OR "permission" OR "Admin") | rex field=_raw "(?i)user[_ ]?id[=:]\s*(?<uid>\d+)" | stats count values(_raw) as events by uid, host | where count > 0

Atomic Red Team Tests

Test 1 Zammad role escalation via rails console (lab)
linux

Simulates an unauthorized grant of the Admin role to a low-privileged user through the Zammad rails runner, reproducing the audit-log side-effect of CVE-2026-102490.

Command

bash 
zammad run rails r 'u = User.find_by(login: "[email protected]"); u.roles = Role.where(name: ["Admin"]); u.save!'

Cleanup

bash 
zammad run rails r 'u = User.find_by(login: "[email protected]"); u.roles = Role.where(name: ["Customer"]); u.save!'

Expected Telemetry

Zammad production.log and PostgreSQL history entry recording a role change to Admin for the target user; process telemetry for the ruby/rails rake invocation under the zammad account.

Expected Detection

KQL/SPL/EQL rules fire on the permission/role grant referencing 'Admin' on a zammad host.

Test 2 Direct permission grant to low-privileged user (lab)
linux

Grants an elevated permission (admin.user) directly, emulating privilege manipulation without a full role change.

Command

bash 
zammad run rails r 'u = User.find_by(login: "[email protected]"); u.permissions = ["admin.user"]; u.save!'

Cleanup

bash 
zammad run rails r 'u = User.find_by(login: "[email protected]"); u.permissions = []; u.save!'

Expected Telemetry

production.log 'Users::Permission' / permission grant entry and corresponding history row.

Expected Detection

Rules match the 'permission'/'Users::Permission' signature in process args and application logs.

Test 3 Suspicious zammad-account process referencing permissions (lab)
linux

Runs a rake task under the zammad service account that references permission tables, generating the process-launch telemetry the endpoint rules key on.

Command

bash 
sudo -u zammad bash -c 'cd /opt/zammad && bundle exec rails r "puts Permission.pluck(:name).grep(/admin/)"'

Cleanup

bash 
echo 'no cleanup required — read-only enumeration'

Expected Telemetry

ProcessRollup2 / auditbeat process event: ruby/rails executed by user 'zammad' with command line containing 'Permission' and 'admin'.

Expected Detection

CrowdStrike CQL and Elastic EQL rules match ruby/rails process by the zammad user referencing permission/admin.

Related Detections

Tactic Hub

TA0004Privilege Escalation

Related Techniques

T1068Exploitation for Privilege EscalationT1078Valid AccountsT1098Account Manipulation

Same Tactic: Privilege Escalation

Popular Detections