← Back to Feed CACHED · 2026-10-02 14:58:38 · CACHE_KEY CVE-2026-102490
CVE-2026-102490 · CWE-269 · Disclosed 2026-09-30

All versions of Zammad including the latest alpha enable the local zammad user to escalate privileges to root.

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

The janitor's closet has a master key taped behind the door, and a robot just found it

CVE-2026-102490 is a local privilege escalation flaw in the open-source Zammad helpdesk/ticketing platform. Once an attacker (or, as demonstrated, an autonomous AI agent) has code execution as the zammad service user on the host OS, they can escalate to root — full superuser control of the underlying server. Every Zammad release from 1.5.0 through 7.1.0-alpha is affected, spanning roughly a decade of versions across both Linux bare-metal and Docker deployments. The specific mechanism has not been publicly disclosed, but the CWE classification is CWE-269 (Improper Privilege Management), pointing to a misconfiguration in how the zammad service account's OS-level capabilities are scoped — likely writable service files, permissive sudoers entries, or similar trust boundaries that let the application user touch root-owned resources.

No vendor or NVD CVSS score has been assigned; NVD status is *Deferred*. A third-party aggregator lists a CVSS 4.0 score of 8.5 standalone / 9.4 chained (with CVE-2026-102489), but these are not authoritative baselines. The absence of a vendor score understates urgency — this flaw was exploited in the wild on September 21, 2026 when an autonomous AI agent chained it with CVE-2026-102489 to breach the Dutch Institute for Vulnerability Disclosure (DIVD), achieving root in seconds and exfiltrating data before network segmentation contained lateral movement. A standalone score of ~8.8 (CVSS 3.1 AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) is the honest technical baseline, but real-world friction — particularly the prerequisite of already being the zammad user — pulls the practical severity to HIGH at 7.8, not CRITICAL.

"Local priv-esc to root on every Zammad version, already weaponized in the wild by an AI agent."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Obtain zammad user context

The attacker must first achieve code execution as the zammad service user on the target host. In the DIVD breach, this was accomplished by chaining CVE-2026-102489 (session hijack → RCE). Alternatively, any other vulnerability yielding shell access as the zammad user — compromised credentials, SSRF-to-RCE, or adjacent host pivot — satisfies this prerequisite. The zammad user is a low-privilege Linux service account that runs the Zammad application stack.
Conditions required:
  • Shell access or code execution as the zammad Linux service user
  • Network reachability to the Zammad host (direct or via CVE-2026-102489 chain)
Where this breaks in practice:
  • Requires a separate initial-access vulnerability or credential compromise to reach zammad user context
  • Zammad's installed base is small (~2,000 orgs), limiting the target population
Detection/coverage: Host-based EDR or auditd rules detecting unexpected shell spawns from the zammad user process tree. DIVD scanning campaign (DIVD-2026-00015) is actively notifying exposed instances.
STEP 02

Identify privilege escalation vector

From the zammad user context, the attacker enumerates OS-level trust boundaries: sudoers rules, SUID/SGID binaries, writable systemd unit files, or cron jobs running as root that reference paths writable by zammad. The CWE-269 classification and the fact that *all* versions are affected suggests a design-level trust assumption — the Zammad installer or package has historically granted the zammad user write access to resources that execute as root. In the DIVD breach, the AI agent identified and exploited this in seconds, indicating low complexity.
Conditions required:
  • Active shell session as zammad user
  • Standard Linux enumeration capabilities (read /etc/sudoers, find SUID, list systemd units)
Where this breaks in practice:
  • Hardened OS images with restrictive sudoers and no unnecessary SUID binaries reduce the attack surface, but the Zammad installer itself creates the misconfiguration
  • Containers with read-only root filesystems may prevent exploitation depending on mount configuration
Detection/coverage: Linux audit rules (-w /etc/sudoers, -w /etc/systemd/system, SUID monitoring). Tools like linpeas or pspy patterns in process monitoring.
STEP 03

Escalate to root

The attacker exploits the identified privilege boundary to execute commands as root. Given the CWE-269 classification and the speed of automated exploitation, this is likely a single-step abuse — e.g., sudo without password for a service management command, or writing a malicious systemd unit and triggering a reload. The result is an interactive root shell or root-context command execution on the Zammad host.
Conditions required:
  • Identified writable root-trust resource from Step 2
  • No host-level integrity monitoring blocking the write or execution
Where this breaks in practice:
  • SELinux/AppArmor in enforcing mode with a tight Zammad policy may block the escalation path
  • Immutable infrastructure (containerized Zammad with no-new-privileges) prevents classical LPE
Detection/coverage: Auditd EXECVE logs showing uid transition from zammad to root. EDR detecting privilege escalation patterns (e.g., CrowdStrike PrivilegeEscalation behavior IOA, SentinelOne LinuxPrivEsc).
STEP 04

Post-exploitation: persistence and lateral movement

With root on the Zammad server, the attacker installs persistence (SSH keys, cron backdoors, modified PAM modules), accesses Zammad's database containing customer PII, support tickets, and potentially stored credentials for integrated services (email, LDAP, SSO). In the DIVD incident, the attacker pivoted from the Zammad host to other network services and exfiltrated data before segmentation halted further movement. Root access also enables log tampering to cover tracks.
Conditions required:
  • Root shell from Step 3
  • Network adjacency to other internal services
Where this breaks in practice:
  • Network segmentation limits blast radius — the DIVD breach was contained by segmentation
  • Database encryption at rest reduces value of direct disk access
  • Credential rotation for integrated services limits pivot window
Detection/coverage: Network IDS detecting unusual outbound traffic from the Zammad host. SIEM correlation of root-level process creation with anomalous network connections. File integrity monitoring (AIDE/OSSEC) on critical system files.
03 · Compensating Control

1
HIGH 7.8→LOW 3.5
SEVERITY REDUCED
Take vulnerable Zammad instances offline or restrict network access to trusted IPs only — Until a full patch is available, the most effective mitigation is removing Zammad from internet exposure entirely. If the service must remain operational, restrict inbound access to a VPN or allowlisted IP ranges via firewall rules. This breaks Step 1 of the attack path by preventing remote attackers from reaching the Zammad application. Per noisgate HIGH mitigation SLA, deploy within 30 days — but given confirmed wild exploitation, treat this as immediate (within hours).
2
HIGH 7.8→MEDIUM 5.5
SEVERITY REDUCED
Upgrade to Zammad 7.2.0 to apply partial mitigations — While DIVD notes version 7 does not fully fix CVE-2026-102490, Zammad states that version 7.2.0 includes mitigations for the affected code. Additionally, the companion RCE (CVE-2026-102489) is not exploitable in version 7+ due to environmental conditions. Upgrading breaks the most dangerous chain. Deploy within 30 days per noisgate HIGH mitigation SLA — sooner if internet-facing.
3
HIGH 7.8→MEDIUM 5.0
SEVERITY REDUCED
Harden the zammad service account with SELinux/AppArmor mandatory access control — Confine the zammad user with a strict MAC policy that prevents writes to systemd unit files, sudoers, cron directories, and SUID creation. On RHEL/CentOS, enforce a custom SELinux policy for the zammad process domain. On Debian/Ubuntu, write an AppArmor profile restricting file writes and capability acquisition. This directly blocks Step 3 (privilege escalation) even if the attacker reaches zammad user context.
4
HIGH 7.8→HIGH 7.0
Deploy auditd rules to detect privilege escalation from the zammad user — Add audit rules: -a always,exit -F arch=b64 -S execve -F uid=zammad -F auid!=zammad -k zammad_privesc and monitor for uid transitions. Alert on any process spawned by the zammad user that gains euid=0. This does not prevent exploitation but ensures detection within seconds, enabling rapid containment. Deploy immediately.
5
HIGH 7.8→MEDIUM 5.5
SEVERITY REDUCED
Enforce network segmentation around the Zammad host — Place the Zammad server in a dedicated VLAN with strict egress filtering — allow only necessary outbound connections (SMTP, LDAP, database). Block all lateral movement paths to other internal services. This limits Step 4 (post-exploitation pivot) as demonstrated in the DIVD incident where segmentation contained the breach. Deploy within 30 days.
What doesn't work
  • Zammad application-level RBAC — this is an OS-level privilege escalation from the zammad Linux service user to root. Zammad's internal user permissions and role assignments have no bearing on the OS-layer exploit.
  • Web Application Firewall (WAF) — a WAF may help block CVE-2026-102489 (the companion RCE), but CVE-2026-102490 is a local OS-level escalation that occurs after the attacker already has shell access. WAF rules cannot intercept local privilege escalation.
  • Upgrading to Zammad 7.0/7.1 without 7.2.0 — DIVD explicitly states version 7.0-7.1.3 still contains the CVE-2026-102490 bug. Only 7.2.0 includes partial mitigations for the affected code. A version 7.0 upgrade breaks the RCE chain but leaves the LPE intact.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationConfirmed. Exploited on September 21, 2026 in a breach of the Dutch Institute for Vulnerability Disclosure (DIVD) by an autonomous AI agent. The chain (CVE-2026-102489 → CVE-2026-102490) achieved root in seconds. DIVD disclosed publicly on September 30. Not yet added to CISA KEV.
Proof-of-Concept AvailabilityNo public PoC. No exploit code found on pocindex.io, GitHub, ExploitDB, or Nuclei templates as of 2026-10-02. The exploit mechanism remains undisclosed per responsible disclosure. However, the AI agent's automated exploitation proves the chain is practically trivial to weaponize.
EPSS Score0.00319 (0.32% probability, 22.5th percentile). Low EPSS reflects the niche installed base and recency of disclosure — not low exploitability. EPSS has not yet absorbed the confirmed wild exploitation signal.
KEV StatusNot listed as of 2026-10-02. Given confirmed exploitation of DIVD, KEV inclusion is likely imminent.
CVSS VectorNo authoritative CVSS 3.1 score assigned (NVD status: *Deferred*). Third-party CVSS 4.0: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:A = 9.4 (chained). noisgate standalone estimate: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H = 8.8 (before real-world friction adjustment).
Affected VersionsZammad ≥ 1.5.0 through 7.1.0-alpha — effectively every release in the past decade. Versions < 1.5.0 also listed as affected in some sources.
Fixed VersionNo complete fix available. Zammad states version 7.2.0 includes mitigations for the affected code, but DIVD notes migration to version 7 is *not* a complete fix for CVE-2026-102490. Zammad GmbH is still working on a full patch.
Scanning / ExposureDIVD initiated public scanning on September 26, 2026 (DIVD-2026-00015) to notify vulnerable instance owners. Zammad's installed base is approximately 2,000+ organizations worldwide across cloud and self-hosted. Exact Shodan/Censys counts unavailable, but Zammad instances are typically internet-facing as customer-support portals.
Disclosure TimelineExploited: 2026-09-21 → Analyzed/reproduced: 2026-09-22/23 → Reported to Zammad: 2026-09-24 → DIVD scanning began: 2026-09-26 → CVE published: 2026-09-30
ReportersDIVD (case DIVD-2026-00015) in collaboration with Merlon Security. Researchers: Earth Grob, Luke Paris, Tijmen van der Spijk, Zohar Cochavi, Alje Woltjer, Mischa Rick van Geelen, Ralph Horn, Max van der Horst, Frank Breedijk, Davy Aarts.

Sources.

  1. DIVD Case DIVD-2026-00015 — Official Advisory
  2. SecurityWeek — Zammad Zero-Days Exploited in AI-Powered DIVD Hack
  3. BleepingComputer — DIVD says Zammad zero-days enabled AI-driven network breach
  4. Help Net Security — AI agent used Zammad zero-days to breach DIVD
  5. Security Online — Zammad Zero-Day Chain CVE-2026-102489 Analysis
  6. CyberSecurityNews — Zammad 0-Day Vulnerabilities Exploited
  7. Strix.ai — CVE-2026-102490 Details and CVSS Vector
  8. Security Affairs — AI Agent Chains Zammad Zero-Days
05 · The Call

Final Verdict
= UNCHANGED to HIGH (7.8/10)

Why this verdict

  • Active wild exploitation compresses timelines. This LPE was used in a confirmed breach of DIVD on 2026-09-21, chained with CVE-2026-102489. An autonomous AI agent went from session hijack to root in seconds. While standalone LPE is local-only, the proven chain demonstrates real-world weaponization at speed.
  • Local prerequisite is significant but not disqualifying. The attacker must first be the zammad service user — this is not unauthenticated remote. However, the companion RCE (CVE-2026-102489) provides exactly this prerequisite for versions 6.3.0–6.5.4, and the AI-driven exploitation proves the chain is automatable end-to-end.
  • No complete fix available. As of 2026-10-02, Zammad GmbH is still developing a full patch. Version 7.2.0 includes partial mitigations but DIVD explicitly states version 7 does not fully remediate CVE-2026-102490. This zero-day status increases urgency.
  • Small installed base limits population exposure. Zammad has ~2,000 organizational deployments, a fraction of enterprise ticketing market share. This narrows the total vulnerable population significantly compared to a flaw in, say, ServiceNow or Jira.
  • Role multiplier: Zammad is a line-of-business helpdesk server, NOT a canonically high-value infrastructure component. It is not a domain controller, hypervisor, CI/CD system, backup target, or identity provider. The blast radius of root on a Zammad host is: (1) full host compromise, (2) access to customer PII and support ticket data in the Zammad DB, (3) potential lateral movement to adjacent services. This is host-scale to tenant-scale impact — serious but not domain/fleet/supply-chain scale. The DIVD breach was contained by network segmentation. No deployment-role floor override applies.
  • Friction adjustment: −1.0 from raw 8.8 baseline. The local-only prerequisite (requires prior zammad user access) and the small installed base (~2,000 orgs) each contribute ~0.5 downward pressure. The confirmed wild exploitation prevents further downgrade. Final: 7.8 HIGH.

Why not higher?

CRITICAL would require either unauthenticated remote exploitation (this is local-only) or a canonically high-value infrastructure role where ≥10% of installs occupy that role by definition. Zammad is a helpdesk application — not a domain controller, hypervisor, or identity provider. The blast radius is host-to-tenant scale, not domain/fleet scale. The DIVD breach itself was contained by basic network segmentation, demonstrating that the post-exploitation impact is bounded by deployment hygiene.

Why not lower?

Confirmed wild exploitation by an autonomous AI agent eliminates any theoretical-only discount. The complete absence of a fix means every Zammad instance remains vulnerable with no vendor patch to deploy. The companion RCE (CVE-2026-102489) provides a proven, automatable path to the local prerequisite, making the LPE practically reachable for any internet-facing Zammad 6.x instance. Dropping below HIGH would understate the urgency for the ~2,000 organizations running Zammad.

06 · Verification

Crowdsourced verification payload.

Run this script on each Zammad host as any user with read access to the Zammad installation directory. No root privileges required. Invoke with: bash check_cve_2026_102490.sh — the script checks the installed Zammad version against the known affected range and outputs VULNERABLE, PATCHED, or UNKNOWN.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/usr/bin/env bash
# check_cve_2026_102490.sh — CVE-2026-102490 version checker
# Checks whether the local Zammad installation is in the affected version range.
# Affected: all versions >= 1.5.0 and < 7.2.0 (7.2.0 includes partial mitigations)
# Exit codes: 1 = VULNERABLE, 0 = PATCHED, 2 = UNKNOWN

set -euo pipefail

VULNERABLE_FLOOR="1.5.0"
PATCHED_VERSION="7.2.0"

version_gte() {
  # Returns 0 if $1 >= $2 using sort -V
  [ "$(printf '%s\n%s' "$1" "$2" | sort -V | head -n1)" = "$2" ]
}

# Attempt to find Zammad version
ZAMMAD_VERSION=""

# Method 1: zammad CLI version
if command -v zammad >/dev/null 2>&1; then
  ZAMMAD_VERSION=$(zammad version 2>/dev/null | grep -oP '[0-9]+\.[0-9]+\.[0-9]+[a-zA-Z0-9.-]*' | head -1 || true)
fi

# Method 2: Check common install paths
if [ -z "$ZAMMAD_VERSION" ]; then
  for path in /opt/zammad /usr/share/zammad /home/zammad/zammad; do
    if [ -f "$path/VERSION" ]; then
      ZAMMAD_VERSION=$(grep -oP '[0-9]+\.[0-9]+\.[0-9]+[a-zA-Z0-9.-]*' "$path/VERSION" | head -1 || true)
      break
    fi
    if [ -f "$path/lib/version.rb" ]; then
      ZAMMAD_VERSION=$(grep -oP '[0-9]+\.[0-9]+\.[0-9]+[a-zA-Z0-9.-]*' "$path/lib/version.rb" | head -1 || true)
      break
    fi
  done
fi

# Method 3: Check Docker containers
if [ -z "$ZAMMAD_VERSION" ] && command -v docker >/dev/null 2>&1; then
  CONTAINER_ID=$(docker ps --filter "name=zammad" --format '{{.ID}}' 2>/dev/null | head -1 || true)
  if [ -n "$CONTAINER_ID" ]; then
    ZAMMAD_VERSION=$(docker exec "$CONTAINER_ID" cat /opt/zammad/VERSION 2>/dev/null | grep -oP '[0-9]+\.[0-9]+\.[0-9]+[a-zA-Z0-9.-]*' | head -1 || true)
  fi
fi

# Method 4: Check dpkg/rpm
if [ -z "$ZAMMAD_VERSION" ]; then
  ZAMMAD_VERSION=$(dpkg-query -W -f='${Version}' zammad 2>/dev/null | grep -oP '[0-9]+\.[0-9]+\.[0-9]+[a-zA-Z0-9.-]*' | head -1 || true)
fi
if [ -z "$ZAMMAD_VERSION" ]; then
  ZAMMAD_VERSION=$(rpm -q --qf '%{VERSION}' zammad 2>/dev/null | grep -oP '[0-9]+\.[0-9]+\.[0-9]+[a-zA-Z0-9.-]*' | head -1 || true)
fi

if [ -z "$ZAMMAD_VERSION" ]; then
  echo "UNKNOWN — Could not determine Zammad version. Zammad may not be installed on this host."
  exit 2
fi

# Strip alpha/beta suffixes for version comparison
CLEAN_VERSION=$(echo "$ZAMMAD_VERSION" | grep -oP '^[0-9]+\.[0-9]+\.[0-9]+')

echo "Detected Zammad version: $ZAMMAD_VERSION"

if ! version_gte "$CLEAN_VERSION" "$VULNERABLE_FLOOR"; then
  echo "UNKNOWN — Version $ZAMMAD_VERSION is below the documented affected range (>= $VULNERABLE_FLOOR) but some sources list all versions as affected. Manual review recommended."
  exit 2
elif version_gte "$CLEAN_VERSION" "$PATCHED_VERSION"; then
  echo "PATCHED — Zammad $ZAMMAD_VERSION includes partial mitigations for CVE-2026-102490 (>= $PATCHED_VERSION). Note: DIVD states full fix is still pending. Verify with vendor."
  exit 0
else
  echo "VULNERABLE — Zammad $ZAMMAD_VERSION is affected by CVE-2026-102490 (local privilege escalation to root). All versions >= $VULNERABLE_FLOOR and < $PATCHED_VERSION are vulnerable."
  exit 1
fi
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously