Like leaving the master key taped under the reception desk — every walk-in customer can grab it
CVE-2026-102489 is a session-hijacking vulnerability in Zammad, the open-source helpdesk and ticketing platform, affecting versions 6.3.0 through 6.5.4. An unauthenticated, remote attacker can deliver crafted content to a Zammad instance — likely via the ticket submission or email-to-ticket flow. When a Zammad agent or administrator views that content (classified as *passive* user interaction in CVSS 4.0), their session is hijacked, and the attacker achieves remote code execution as the zammad system user on the underlying Linux host. The flaw also exists in versions 7.0.0–7.1.3 but is reportedly non-exploitable due to environmental differences in those releases. The remediation is upgrading to Zammad 7.x.
No official NVD or vendor CVSS score exists. The DIVD CNA published a CVSS 4.0 base of 8.7 (HIGH) standalone and 9.4 (CRITICAL) when chained with CVE-2026-102490 (local privilege escalation to root). noisgate assesses the standalone CVE at HIGH (8.5). The 'passive user interaction' requirement sounds like friction on paper, but in a helpdesk product where agents *must* view tickets from untrusted external users, it is functionally zero — the 'interaction' *is* the agent's core job. The confirmed active exploitation against DIVD on September 21, 2026 — by an autonomous AI agent that chained both zero-days and reached root in seconds — validates that this chain is weaponized, fast, and does not require human operator skill. The only brake on a CRITICAL standalone rating is that Zammad is not a canonical high-value-role component and its installed base (~2,000 enterprise customers) bounds fleet-scale blast radius.
5 steps from start to impact.
Locate internet-facing Zammad instance
inurl:"/api/v1" "Zammad"). Zammad is a customer-facing helpdesk — it is designed to be internet-accessible. DIVD began scanning for exposed instances on September 26, 2026 and found a significant population.- Target runs Zammad 6.3.0–6.5.4
- Zammad web interface is reachable from the internet
- Organizations running Zammad behind a VPN or zero-trust proxy are not reachable
- Instances already upgraded to 7.x are non-exploitable
Deliver crafted payload via ticket or email
PR:N/UI:P) confirms no credentials are needed.- Ability to submit a ticket or send email to Zammad's intake address
- Zammad's ticket/email intake is enabled (default)
- WAF or email gateway *might* catch the payload if signatures existed, but none are published yet
- Custom CSP headers could mitigate if the mechanism is XSS-based, but this is unconfirmed
/var/log/zammad for ERROR entries containing "Cookie"=> or @clients={} strings indicating session material exposure.Agent views ticket — session hijacked
- At least one Zammad agent must view the crafted ticket
- Agent's browser must execute the payload (standard, non-hardened browser is sufficient)
- If no agent ever views the ticket, the chain stalls — but helpdesk SLAs typically guarantee a response within hours
- Browser-side exploit mitigations (site isolation, strict CSP) could theoretically interfere, but the exploit succeeded against DIVD's production environment
sessions table or nginx access logs. SIEM correlation on X-Forwarded-For mismatches.Abuse Zammad internals for code execution
zammad system user. The AI agent in the DIVD breach completed this step within seconds.- Hijacked session has sufficient privileges (agent or admin)
- Zammad application permits the code-execution vector (likely an admin feature or Rails deserialization path)
- If the hijacked session belongs to a low-privilege agent without admin access, additional privilege escalation within Zammad may be needed
- Principle-of-least-privilege configurations limiting admin accounts reduce the pool of useful sessions
RCE as zammad user — data access and pivot
zammad system user. This grants read access to all ticket data, customer PII, internal agent notes, and stored email credentials (IMAP/POP3/OAuth tokens Zammad uses to fetch and send mail). The attacker can exfiltrate this data, plant backdoors, or pivot into the internal network. In the DIVD breach, the attacker combined this with CVE-2026-102490 to escalate to root within seconds, gaining full host control.- Successful code execution from Step 4
- Network segmentation can limit lateral movement (this saved DIVD from deeper compromise)
- Host-based EDR should detect the initial shell and alert, but may not prevent data access if the process runs under a legitimate service account
zammad user's outbound connectivity to only required destinations (database, email servers, Redis/Elasticsearch). Block outbound SSH, HTTP to arbitrary IPs, and DNS to external resolvers. This limits data exfiltration and lateral movement if RCE is achieved. DIVD credited network segmentation with preventing deeper compromise. Deploy within the noisgate mitigation SLA (30 days for HIGH, but preferably within days given active exploitation)./var/log/zammad and /var/log/nginx for ERROR entries containing "Cookie"=> or @clients={} strings — these are indicators of session material exposure per DIVD's published IoC guidance. Forward Zammad and nginx logs to your SIEM. Alert on session tokens used from multiple source IPs and on unusual child processes spawned by the Zammad Ruby/Puma workers. This is detection, not prevention — it tells you if you've already been hit.- Generic WAF rules — No public exploit signatures exist. Without knowledge of the specific payload, standard OWASP CRS or vendor WAF rulesets will not reliably detect or block the attack. The DIVD breach succeeded against a production environment presumably behind standard web infrastructure.
- Content Security Policy headers — If the session hijack mechanism is XSS-based, strict CSP *might* interfere, but the root cause is undisclosed. CSP is also only effective if the Zammad deployment has customized its headers (default Zammad CSP may not be strict enough). Do not rely on this.
- Email gateway filtering — If the attack vector is email-to-ticket, the malicious content becomes a Zammad ticket that agents view in the web UI. The email gateway processes the inbound email, but the exploit triggers in the *browser* when an agent opens the rendered ticket. Email-layer scanning cannot prevent browser-side exploitation of rendered content.
- Restricting Zammad REST API access — The attack appears to target the ticket/email intake workflow and the web UI session, not the API. Disabling or restricting API endpoints does not address the attack path.
The supporting signals.
| In-the-Wild Exploitation | Confirmed. DIVD (Dutch Institute for Vulnerability Disclosure) was breached on September 21, 2026 via this exact CVE chained with CVE-2026-102490. An autonomous AI agent exploited the chain, reaching root in seconds. DIVD published the case as DIVD-2026-00015. Not yet on CISA KEV. |
|---|---|
| Proof-of-Concept Availability | No public PoC. DIVD has deliberately withheld technical details and attack requests. No repos found on GitHub named after the CVE. pocindex.io returned no results. The SecureWithUmer/CVE-2026-PoCs aggregator does not list this CVE. The AI agent that exploited it apparently discovered the attack path autonomously without a published PoC. |
| EPSS Score | 0.00709 (0.71%), approximately 48th percentile. Low probability reflects the 2-day-old disclosure and absence of public exploit code. Expect this to climb as details emerge. |
| CISA KEV Status | Not listed as of 2026-10-02. Given confirmed exploitation of a security research organization, KEV addition is likely imminent. |
| CVSS 4.0 Vector | CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L/E:A/AU:Y/V:C — Network-reachable, low complexity, no privileges, passive user interaction, high direct impact, attacked exploit maturity, automatable, confirmed vulnerability. |
| Affected Versions | Exploitable: Zammad 6.3.0 – 6.5.4. Present but non-exploitable: 7.0.0 – 7.1.3 (environmental conditions prevent exploitation). Not affected: < 6.3.0. |
| Fixed Version | Zammad 7.0.0+ (bug present but non-exploitable). DIVD recommends upgrading to version 7 or taking systems offline. No backport patch for the 6.x branch has been announced. |
| Scanning / Exposure | DIVD began scanning for publicly exposed vulnerable Zammad instances on September 26, 2026 and started notifying owners. Zammad claims ~2,000 enterprise customers and ~55,000 individual users globally. Exact Shodan/Censys counts for vulnerable versions not published, but helpdesk systems are internet-facing by design. |
| Disclosure Timeline | Sep 21: DIVD breached via Zammad zero-days. Sep 22–23: Analysis and reproduction. Sep 24: Vendor (Zammad GmbH) notified; AI-agent nature disclosed publicly. Sep 26: DIVD begins scanning; victim notifications start. Sep 30: CVE IDs published. Oct 1: Full public disclosure. |
| Researchers / Reporting Org | Discovered during incident response by DIVD and Merlon Security. Key researchers: Earth Grob, Luke Paris, Tijmen van der Spijk, Zohar Cochavi, Alje Woltjer (Merlon); Mischa Rick van Geelen, Ralph Horn, Max van der Horst, Frank Breedijk, Davy Aarts (DIVD). |
Sources.
- DIVD Case DIVD-2026-00015 (authoritative advisory)
- SecurityWeek — Zammad Zero-Days Exploited in AI-Powered DIVD Hack
- Help Net Security — AI agent used Zammad zero-days to breach DIVD
- Security Online — Zammad Zero-Day Chain CVE-2026-102489 Exploited in the Wild
- Security Affairs — AI Agent Chains Zammad Zero-Days
- Dev.to — Two Zammad Zero-Days: DIVD Reports Session Compromise
- ThreatInt CVE Record — CVE-2026-102489
- Offseq Threat Radar — CVE-2026-102489
Why this verdict
- Active exploitation confirmed: An autonomous AI agent exploited this zero-day to breach DIVD on September 21, 2026, chaining it with CVE-2026-102490 to reach root in seconds. This is not theoretical — it is weaponized and in use.
- Functionally zero user-interaction friction: CVSS lists UI:P (passive interaction), but the 'interaction' is a helpdesk agent viewing a ticket — the product's primary function. In any operational Zammad deployment, agents view incoming tickets within minutes to hours per SLA. This is not a 'trick the user into clicking a link' scenario; it is built into the workflow.
- No authentication required, internet-facing by design: PR:N and Zammad's deployment model as a customer-facing helpdesk mean the attacker needs only internet access and the ability to submit a ticket or send an email. The attack surface is the product's front door.
- Automatable at scale (AU:Y): The CVSS record confirms automated exploitation is feasible. The AI agent demonstrated this capability in practice — no human direction was required per DIVD's report.
- Role multiplier: Zammad occupies a line-of-business helpdesk role in virtually all deployments. It is NOT a canonical high-value component (not IdP, DC, hypervisor, PAM, backup, CA, or network edge). In its typical role, successful exploitation yields: (1) host-level RCE as unprivileged
zammaduser, (2) read access to all ticket data, customer PII, and stored email credentials (IMAP/POP3/OAuth), (3) potential pivot into internal network from the DMZ/web tier. The blast radius is host + application data, not fleet-scale or domain-scale without chaining CVE-2026-102490. For organizations like DIVD that handle sensitive vulnerability disclosures through Zammad, the data impact is acute but still application-bounded. This caps the standalone verdict at HIGH rather than CRITICAL. - No public PoC constrains mass exploitation — for now: DIVD withheld technical details. No GitHub repos, Nuclei templates, or Metasploit modules exist. The AI agent found the attack path independently, but human attackers lack a published recipe. This is a temporary brake; expect PoCs within weeks.
Why not higher?
CRITICAL would require fleet-scale, domain-scale, or supply-chain impact, or the affected component being a canonical high-value-role product (IdP, DC, hypervisor, etc.). Zammad is a line-of-business helpdesk with ~2,000 enterprise customers — significant, but not ubiquitous infrastructure. The standalone CVE yields code execution as the unprivileged zammad user, not root (root requires chaining CVE-2026-102490). The blast radius is bounded to the host and application data. If assessing the *chained* pair (CVE-2026-102489 + CVE-2026-102490), CRITICAL would be warranted.
Why not lower?
Active, confirmed exploitation of a real organization (DIVD) by an autonomous AI agent rules out anything below HIGH. The attack requires no authentication, targets an internet-facing service, needs only routine user behavior to trigger, and is automatable. The CVSS 4.0 base with E:A (Attacked) maturity is 8.7, and real-world evidence fully supports that assessment. Downgrading below HIGH would require evidence that the installed base is negligibly small (<0.1% of enterprises) or that the attack path has been neutralized — neither is true.
Crowdsourced verification payload.
Run this script on each Zammad host as any user with read access to the Zammad installation directory (default /opt/zammad). Usage: bash check_cve_2026_102489.sh or bash check_cve_2026_102489.sh /custom/zammad/path. No elevated privileges required for version check; root or zammad-group membership needed for IoC log check.
#!/usr/bin/env bash
# CVE-2026-102489 — Zammad Session Hijack → RCE version check + IoC scan
# Outputs: VULNERABLE / PATCHED / UNKNOWN
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=VULNERABLE+IoC, 3=UNKNOWN
set -uo pipefail
ZAMMAD_DIR="${1:-/opt/zammad}"
VULN_MIN="6.3.0"
VULN_MAX="6.5.4"
RESULT="UNKNOWN"
IOC_FOUND=0
# --- Version detection ---
VERSION=""
if [[ -f "$ZAMMAD_DIR/VERSION" ]]; then
VERSION=$(tr -d '[:space:]' < "$ZAMMAD_DIR/VERSION")
elif command -v zammad &>/dev/null; then
VERSION=$(zammad version 2>/dev/null | grep -oP '[0-9]+\.[0-9]+\.[0-9]+' | head -1 || true)
fi
if [[ -z "$VERSION" ]]; then
echo "UNKNOWN — Cannot determine Zammad version."
echo "Checked: $ZAMMAD_DIR/VERSION and 'zammad version' command."
echo "If Zammad is installed elsewhere, pass the path as an argument."
exit 3
fi
echo "[*] Detected Zammad version: $VERSION"
# --- Version comparison (sort -V based) ---
ver_gte() { printf '%s\n%s\n' "$2" "$1" | sort -V -C; }
ver_lte() { printf '%s\n%s\n' "$1" "$2" | sort -V -C; }
if ver_gte "$VERSION" "$VULN_MIN" && ver_lte "$VERSION" "$VULN_MAX"; then
RESULT="VULNERABLE"
echo "[!] VULNERABLE — Zammad $VERSION is in the affected range ($VULN_MIN – $VULN_MAX)"
echo " Remediation: Upgrade to Zammad 7.x immediately."
elif ver_gte "$VERSION" "7.0.0" && ver_lte "$VERSION" "7.1.3"; then
RESULT="PATCHED"
echo "[+] PATCHED — Zammad $VERSION contains the code but is NOT exploitable (environmental conditions)."
elif ver_gte "$VERSION" "7.1.4"; then
RESULT="PATCHED"
echo "[+] PATCHED — Zammad $VERSION is beyond all affected ranges."
else
RESULT="PATCHED"
echo "[+] PATCHED — Zammad $VERSION is below the affected range (< $VULN_MIN)."
fi
# --- IoC check (DIVD indicators) ---
echo ""
echo "[*] Checking for known IoCs (DIVD-2026-00015)..."
for LOGDIR in /var/log/zammad /var/log/nginx; do
if [[ -d "$LOGDIR" ]] && [[ -r "$LOGDIR" ]]; then
# Check for session material exposure in logs
HITS=$(grep -rl '"Cookie"=>' "$LOGDIR" 2>/dev/null | head -5 || true)
if [[ -n "$HITS" ]]; then
echo "[!!] IoC DETECTED — Session cookie exposure in $LOGDIR:"
echo "$HITS"
IOC_FOUND=1
fi
HITS2=$(grep -rl '@clients={}' "$LOGDIR" 2>/dev/null | head -5 || true)
if [[ -n "$HITS2" ]]; then
echo "[!!] IoC DETECTED — @clients={} pattern in $LOGDIR:"
echo "$HITS2"
IOC_FOUND=1
fi
else
echo "[~] Skipped $LOGDIR (not found or not readable — run as root for full IoC check)"
fi
done
if [[ $IOC_FOUND -eq 1 ]]; then
echo ""
echo "[!!] INDICATORS OF COMPROMISE FOUND — Investigate immediately."
echo " Refer to DIVD-2026-00015: https://csirt.divd.nl/cases/DIVD-2026-00015/"
else
echo "[+] No known IoCs detected in accessible log files."
fi
# --- Final output ---
echo ""
if [[ "$RESULT" == "VULNERABLE" ]] && [[ $IOC_FOUND -eq 1 ]]; then
echo "VULNERABLE (with IoC hits — possible active compromise)"
exit 2
elif [[ "$RESULT" == "VULNERABLE" ]]; then
echo "VULNERABLE"
exit 1
elif [[ "$RESULT" == "PATCHED" ]]; then
echo "PATCHED"
exit 0
else
echo "UNKNOWN"
exit 3
fi