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.
4 steps from start to impact.
Obtain zammad user context
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.- Shell access or code execution as the
zammadLinux service user - Network reachability to the Zammad host (direct or via CVE-2026-102489 chain)
- Requires a separate initial-access vulnerability or credential compromise to reach
zammaduser context - Zammad's installed base is small (~2,000 orgs), limiting the target population
zammad user process tree. DIVD scanning campaign (DIVD-2026-00015) is actively notifying exposed instances.Identify privilege escalation vector
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.- Active shell session as
zammaduser - Standard Linux enumeration capabilities (read /etc/sudoers, find SUID, list systemd units)
- 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
-w /etc/sudoers, -w /etc/systemd/system, SUID monitoring). Tools like linpeas or pspy patterns in process monitoring.Escalate to root
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.- Identified writable root-trust resource from Step 2
- No host-level integrity monitoring blocking the write or execution
- 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
zammad to root. EDR detecting privilege escalation patterns (e.g., CrowdStrike PrivilegeEscalation behavior IOA, SentinelOne LinuxPrivEsc).Post-exploitation: persistence and lateral movement
- Root shell from Step 3
- Network adjacency to other internal services
- 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
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.-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.- Zammad application-level RBAC — this is an OS-level privilege escalation from the
zammadLinux service user toroot. 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.
The supporting signals.
| In-the-Wild Exploitation | Confirmed. 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 Availability | No 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 Score | 0.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 Status | Not listed as of 2026-10-02. Given confirmed exploitation of DIVD, KEV inclusion is likely imminent. |
| CVSS Vector | No 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 Versions | Zammad ≥ 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 Version | No 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 / Exposure | DIVD 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 Timeline | Exploited: 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 |
| Reporters | DIVD (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.
- DIVD Case DIVD-2026-00015 — Official Advisory
- SecurityWeek — Zammad Zero-Days Exploited in AI-Powered DIVD Hack
- BleepingComputer — DIVD says Zammad zero-days enabled AI-driven network breach
- Help Net Security — AI agent used Zammad zero-days to breach DIVD
- Security Online — Zammad Zero-Day Chain CVE-2026-102489 Analysis
- CyberSecurityNews — Zammad 0-Day Vulnerabilities Exploited
- Strix.ai — CVE-2026-102490 Details and CVSS Vector
- Security Affairs — AI Agent Chains Zammad Zero-Days
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
zammadservice 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
zammaduser 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.
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.
#!/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