← Back to Feed CACHED · 2026-10-02 04:52:47 · CACHE_KEY CVE-2026-102489
CVE-2026-102489 · Disclosed 2026-09-30

Zammad versions 6.3.0 to 6.5.4 are vulnerable a session hijack vulnerability that leads to remote code…

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

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.

"Actively exploited zero-day in Zammad helpdesk: submit a ticket, steal a session, own the box."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Locate internet-facing Zammad instance

The attacker identifies a publicly reachable Zammad helpdesk via Shodan, Censys, FOFA, or simple Google dorking (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.
Conditions required:
  • Target runs Zammad 6.3.0–6.5.4
  • Zammad web interface is reachable from the internet
Where this breaks in practice:
  • Organizations running Zammad behind a VPN or zero-trust proxy are not reachable
  • Instances already upgraded to 7.x are non-exploitable
Detection/coverage: Shodan/Censys will enumerate exposed Zammad instances. Passive DNS or certificate transparency logs can identify Zammad subdomains.
STEP 02

Deliver crafted payload via ticket or email

The attacker submits a malicious support ticket or sends a crafted email that Zammad ingests via its email-to-ticket pipeline. No authentication is required — external ticket submission is the product's core use case. The payload contains the session-hijack trigger. The exact mechanism is undisclosed by DIVD, but the CVSS vector (PR:N/UI:P) confirms no credentials are needed.
Conditions required:
  • Ability to submit a ticket or send email to Zammad's intake address
  • Zammad's ticket/email intake is enabled (default)
Where this breaks in practice:
  • 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
Detection/coverage: No public detection signatures as of 2026-10-02. DIVD IoC script checks /var/log/zammad for ERROR entries containing "Cookie"=> or @clients={} strings indicating session material exposure.
STEP 03

Agent views ticket — session hijacked

A Zammad agent or administrator opens the malicious ticket in their browser. This is the 'passive user interaction' (CVSS UI:P): the user performs a routine, expected action. The attacker's payload triggers, and the agent's session token is leaked or overwritten, granting the attacker an authenticated session with the victim's privileges. In the DIVD breach, the AI agent described this step as happening autonomously.
Conditions required:
  • At least one Zammad agent must view the crafted ticket
  • Agent's browser must execute the payload (standard, non-hardened browser is sufficient)
Where this breaks in practice:
  • 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
Detection/coverage: Anomalous session activity: look for a single session token used from multiple source IPs in Zammad's sessions table or nginx access logs. SIEM correlation on X-Forwarded-For mismatches.
STEP 04

Abuse Zammad internals for code execution

Using the hijacked session (potentially an admin session), the attacker leverages Zammad functionality to achieve code execution on the host. Zammad is a Ruby on Rails application; admin-level access can enable trigger/macro abuse, integration configuration (webhooks, LDAP, email), or direct exploitation of Rails internals. The code runs as the zammad system user. The AI agent in the DIVD breach completed this step within seconds.
Conditions required:
  • Hijacked session has sufficient privileges (agent or admin)
  • Zammad application permits the code-execution vector (likely an admin feature or Rails deserialization path)
Where this breaks in practice:
  • 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
Detection/coverage: Monitor Zammad audit logs for unexpected admin actions (trigger creation, integration changes, webhook modifications). EDR on the Zammad host should flag unusual child processes spawned by the Ruby/Puma worker.
STEP 05

RCE as zammad user — data access and pivot

The attacker now has a shell as the 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.
Conditions required:
  • Successful code execution from Step 4
Where this breaks in practice:
  • 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
Detection/coverage: EDR/auditd alerts for shell spawning under the zammad user. Network monitoring for unusual outbound connections from the Zammad host (data exfiltration). File integrity monitoring on Zammad configuration and credential files.
03 · Compensating Control

1
HIGH 8.5→IGNORE 0.0
SEVERITY REDUCED
Upgrade to Zammad 7.x immediately — This is the definitive fix. Zammad 7.0.0+ contains the vulnerable code but environmental conditions prevent exploitation. Given confirmed active exploitation, deploy within hours — not the standard 30-day noisgate mitigation SLA for HIGH. Test in staging if you have one; if not, the risk of staying on 6.x outweighs upgrade risk. No backport patch exists for the 6.x branch.
2
HIGH 8.5→MEDIUM 5.0
SEVERITY REDUCED
Place Zammad behind a VPN or zero-trust gateway — If immediate upgrade is impossible, remove Zammad from direct internet exposure within hours. Require VPN or ZTNA authentication before any user can reach the Zammad web interface. This breaks Step 1 of the attack path (internet reachability) and forces the attacker to first compromise VPN credentials. Accept that internal users can still trigger the chain. External customers will lose self-service ticket access — communicate alternate channels (email-only, phone).
3
HIGH 8.5→IGNORE 0.0
SEVERITY REDUCED
Take vulnerable Zammad instances offline — If you cannot upgrade or place behind VPN, shut down the Zammad service entirely. This eliminates all attack surface. Deploy within hours given active exploitation. Redirect support traffic to email aliases or an alternate ticketing system.
4
HIGH 8.5→HIGH 7.0
Restrict Zammad host network egress — Apply host-firewall or network-segmentation rules limiting the 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).
5
HIGH 8.5→HIGH 8.0
Run DIVD IoC check and enable log monitoring — Immediately check /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.
What doesn't work
  • 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.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationConfirmed. 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 AvailabilityNo 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 Score0.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 StatusNot listed as of 2026-10-02. Given confirmed exploitation of a security research organization, KEV addition is likely imminent.
CVSS 4.0 VectorCVSS: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 VersionsExploitable: 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 VersionZammad 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 / ExposureDIVD 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 TimelineSep 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 OrgDiscovered 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.

  1. DIVD Case DIVD-2026-00015 (authoritative advisory)
  2. SecurityWeek — Zammad Zero-Days Exploited in AI-Powered DIVD Hack
  3. Help Net Security — AI agent used Zammad zero-days to breach DIVD
  4. Security Online — Zammad Zero-Day Chain CVE-2026-102489 Exploited in the Wild
  5. Security Affairs — AI Agent Chains Zammad Zero-Days
  6. Dev.to — Two Zammad Zero-Days: DIVD Reports Session Compromise
  7. ThreatInt CVE Record — CVE-2026-102489
  8. Offseq Threat Radar — CVE-2026-102489
05 · The Call

Final Verdict
= UNCHANGED to HIGH (8.5/10)

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 zammad user, (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.

06 · Verification

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.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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
Peer Review

What defenders are saying.

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