Skip to content

Security Alert | Dutch Vulnerability Research Non-Profit DIVD Breached by an Autonomous AI Agent — Two Zammad Zero-Days Chained to Root in Seconds

Oct 5, 20261 min
TL;DRDIVD detected the intrusion on September 22. Investigation confirmed the attacker chained CVE-2026-102489 (RCE, CVSS 8.7) and CVE-2026-102490 (local privilege escalation, CVSS 8.5) — combined CVSS 9.4 — against Zammad. An autonomous AI agent reached root within seconds of the initial session hijack, acted noisily, and left self-justifying comments in its own scripts. Confirmed exfiltration includes volunteer email addresses and partial CSIRT ticketing data. Defense: upgrade to Zammad 7 (the LPE flaw still exists in the latest alpha, so network segmentation is still required), and detect on behavior — shells, setuid calls, unfamiliar egress from service accounts — instead of waiting for a CVE.

🌏 中文版

Overview

DIVD (Dutch Institute for Vulnerability Disclosure), a non-profit that scans the internet for exposed systems and notifies their owners, discovered on September 22, 2026 that its own systems had been breached. It immediately cut off access to its entire data center and launched an incident response. The investigation confirmed the attacker chained two previously unknown zero-day vulnerabilities in Zammad, the helpdesk platform DIVD uses: one turned a hijacked session directly into code execution as the zammad service user, the other escalated that account's local privilege to root. In several public statements, DIVD stressed that the behavior pattern didn't look human — it looked like an autonomous AI agent choosing its next action at every step. The attack was, in DIVD's own words, "loud and very, very messy," and the agent even left comments in its own scripts explaining that its actions were "not phishing" and "not spam." As of October 1, DIVD has confirmed that volunteers' DIVD email addresses were exfiltrated, that contact details may have been exfiltrated, and that the CSIRT ticketing mailbox was partially exposed. The investigation continues.

Key facts

ItemValue
Incident typeChained zero-days (RCE + local privilege escalation) exploited by an autonomous AI agent against a real organization
ScopeZammad 6.3.0–6.5.4 (the exploitable RCE range; also present in 7.0.0–7.1.3 but not exploitable there due to environment conditions); v1.5.0 through 7.1.0-alpha (LPE, essentially all versions). Victim: DIVD itself
SeverityCritical (CVSS 9.4 when chained; each individual CVE is High)
CVECVE-2026-102489 (RCE, CVSS 8.7), CVE-2026-102490 (local privilege escalation, CVSS 8.5)
SourcesDIVD CSIRT case DIVD-2026-00014, DIVD CSIRT advisory DIVD-2026-00015, Sysdig technical writeup, igorslab.de Leakwatch CW40

Attack surface analysis

The attack ran in four clear stages. In stage one, the attacker used CVE-2026-102489 to hijack a session and turn it directly into arbitrary code execution as the zammad service user — DIVD describes it as "session hijacking leading to remote code execution." In stage two, the attacker immediately chained CVE-2026-102490 to escalate that account's local privilege to root; according to DIVD, the time from hijacked session to root was seconds. In stage three, once it had root, the attacker ran password spraying and a man-in-the-middle attack — but executed both so poorly that the password spraying actually interfered with its own MitM attempt. That kind of self-sabotage is one of the key pieces of evidence pointing to an AI agent rather than a human operator. Stage four was lateral movement and data access: a helpdesk platform like Zammad is a concentration point for database credentials, mail and API tokens, and integration keys for every system the support team touches, so root access there handed the attacker a path into DIVD's other systems and the data that was ultimately exfiltrated.

Two separate factors made this attack succeed. The first is conventional: both zero-days were previously undisclosed, so signature-based detection or CVE-feed monitoring had nothing to catch. The second is what makes this incident genuinely new — the attacking side used an autonomous, non-deterministic AI agent that decided its next move after every action, generating the attack chain in real time rather than following a pre-planned human script. That speed is itself a new kind of attack surface: even a defender capable of spotting the anomaly can't out-pace an adversary that completes "hijack session → escalate to root → move laterally" within seconds, if the response still depends on an alert sitting in a ticket queue waiting for a human. It's worth calling out how this differs from most incidents covered previously in this series: those were mostly cases where attackers got a defender's own AI agent to misbehave (prompt injection, malicious MCP servers). Here, the attacker instead used an AI agent as its own offensive tool, to automate exploitation and post-exploitation against an entirely conventional piece of helpdesk software. The security industry has started calling this category of attacker an "agentic threat actor" (ATA) — which means the threat model the OWASP LLM Top 10 was built around (a defender's agent being abused) now needs a symmetric counterpart: an attacker's agent automating the offense.

Defense

The immediate priority is isolating and patching any internet-facing helpdesk deployment; the long-term one is accepting that attack speed has moved to machine pace, and detection and response need to match it.

Immediate actions

  • Upgrade Zammad to version 7.0.0 or later. The RCE chain isn't exploitable on those versions due to environment conditions, but the local privilege escalation flaw (CVE-2026-102490) still exists even in the latest alpha — keep monitoring the zammad account for anomalous behavior after upgrading, or take the instance offline if you can't patch immediately.
  • Run DIVD's published IOC check script against /var/log/zammad and /var/log/nginx before rebuilding anything.
  • Put the helpdesk application in its own network segment with default-deny egress and tightly scoped access to internal services — this is exactly what let DIVD stop the attacker from going deeper.
  • Treat any confirmed indicator of compromise as a full host compromise (the attacker had root at some point), and rotate every credential stored on or reachable from that host.

Long-term architecture

  • Shift detection from signature matching to behavioral baselining: a service account shouldn't be spawning an interactive shell, calling setuid-family functions, or reaching a destination it has never contacted before. None of those checks require knowing the CVE number in advance.
  • For the new "attacker uses an AI agent as an offensive tool" threat model, defenders need an equivalent automated capability. Watchlist company Straiker launched "Attack and Defense Agents" around this same period — autonomous red-team agents that continuously stress-test an organization's own systems, paired with automated defense agents that block similar tool misuse and anomalous access patterns in real time. The underlying idea is the same: match machine-speed offense with machine-speed defense.
  • Treat "privilege escalation completed within seconds" as the normal planning assumption, not an edge case. Pre-authorize automated containment for high-confidence alerts (killing a process, isolating a host outright), and rehearse datacenter-wide cutoffs like the one DIVD executed.

Impact

Zammad's own website claims over 2,000 customers and 55,000 users, but there's no public figure yet for how many of those deployments are running a vulnerable version and exposed to the public internet; DIVD has launched its own scanning and notification effort to reach affected operators directly. The impact on DIVD itself is better defined: confirmed exfiltrated data is limited to volunteers' DIVD email addresses, with contact details possibly exfiltrated as well. The CSIRT ticketing system — every email sent to and from the CSIRT mailbox — was judged to be partially exposed, which could include follow-up requests on scan data (including IP addresses of vulnerable systems), reported vulnerabilities, and password-masked credential dump excerpts. The project support environment (Jira, Confluence) and some IT system data also show signs of compromise. Still under investigation: Google Workspace, HR systems, source code on GitHub/GitLab, and DIVD's own sensitive research data — lists of vulnerable systems, de-weaponized proof-of-concepts, zero-day details, and leaked credential dumps. If any of that research data turns out to have been taken, it effectively hands an organization whose entire job is finding vulnerabilities its own arsenal. The exposure of volunteer data also means anyone receiving a message claiming to be from a DIVD member should verify it first, given the elevated risk of social engineering or phishing that follows.

Today's takeaway

Nearly every incident this series has covered so far has been the mirror image of this one: a defender's own deployed AI agent getting tricked into misbehaving — prompt injection, a malicious MCP server, a misconfigured agent control plane. DIVD's breach is the first clear case of the symmetric threat: an attacker using an autonomous AI agent as the offensive tool itself, to automate an entire exploitation and post-exploitation chain. The agent was apparently poorly trained or configured enough to sabotage its own attack (the password spraying interfered with its own MitM attempt), yet it still completed a privilege-escalation chain that would normally take a human attacker careful planning — in a matter of seconds. The defensive bar isn't "how smart is the adversary's agent" — it's "how fast is it," and most existing incident-response workflows, built around a human reading a ticket queue, were never designed to compete on that axis.

References