An AI Agent Breached the Group That Hunts Vulnerabilities for a Living. It Took Seconds to Go From Session Hijack to Root.

The Dutch Institute for Vulnerability Disclosure — DIVD, the volunteer nonprofit whose internet-wide scans have fed vulnerability data into CISA's own Known Exploited Vulnerabilities catalog for seven years — just became the victim in one of its own case files. On September 21, 2026, something got into DIVD's network. By the time its own incident responders cut the data center off the next day, the intruder had already hijacked a session, run code, escalated to root, and started pulling data out — DIVD says the whole chain happened "in a matter of seconds," and it is blaming the speed on an autonomous AI agent, not a human at a keyboard.

How the chain actually works

Two bugs, two very different access requirements, chained into one outcome. CVE-2026-102489 is a session-fixation flaw (CWE-384) in Zammad's open-source helpdesk platform, versions 6.3.0 through 6.5.4, that lets an attacker hijack a session and run code as the low-privilege zammad service account — DIVD calls it "a session hijack that led to code execution as the zammad service user." On its own that gets you a foothold, nothing more. CVE-2026-102490 is the escalator: an improper-privilege-management bug (CWE-269) present in every Zammad release from 1.5.0 up to the 7.1.0-alpha branch, letting the already-compromised zammad local user walk straight to root. Chain them and you go from an unauthenticated web request to root on the box without ever needing a password.

What DIVD actually watched happen

That's DIVD's own characterization, and it's worth taking seriously precisely because DIVD is not a hype shop — it's the organization whose day job is finding and responsibly disclosing vulnerabilities, the same scanning discipline that regularly surfaces CVEs that end up in CISA's catalog. Its case for "agentic" isn't a vibe; it's specific and checkable against what it actually observed: the actor left behind self-explanatory comments over-narrating its own reasoning, ran a password-spraying attempt and an adversary-in-the-middle attack at the same time in a way that undermined both, and moved through the hijack-to-root chain in what DIVD calls seconds rather than the hours or days a manual operator would need to reconnoiter and pivot.

The irony, and the limits of it

DIVD exists to find vulnerable systems before attackers do and push operators to patch — the exact workflow that produces entries in CISA's KEV catalog, the same catalog that now lists DIVD's own breach. That's a genuinely sharp irony, but it's worth not overselling: DIVD wasn't hacked because it was careless about its own hygiene. It was hacked because two zero-days existed in third-party helpdesk software it ran, and nobody — DIVD included — knew about them until the chain was already live inside its network. Zero-day is zero-day regardless of who the victim is.

A disclosure dispute, in real time

What defenders can actually check for

Neither CVE has a public exploit or PoC in our own index as of this writing, and DIVD has not published IOCs like hashes, IPs, or domains — the attack was specific enough to one environment that atomic indicators probably won't travel. What it did publish is a behavior-based detection script and guidance, cited via Sysdig's technical writeup of the case:

Flag:
- Zammad app process tree (Rails/Puma/workers) spawning shells, downloading tools, or reaching new outbound hosts
- New session activity from unfamiliar source IPs shortly after a login
- Root-UID processes or new root-owned children under the Zammad process tree
- setuid-family syscalls originating from the `zammad` user
- Mass credential-file reads, multi-account auth failures from a single source, filesystem sweeps by non-baseline processes
- Outbound connections to never-before-seen destinations or unusual upload volume
- New, unexplained tooling dropped in temp directories

1. Inventory every Zammad instance you run, including ones spun up for internal IT/helpdesk use that nobody thinks of as internet-facing.
2. If you're on 6.5.x or earlier, you're in the confirmed-exploitable range for CVE-2026-102489 under both DIVD's and Zammad's accounts — patch or isolate now.
3. If you're on 7.0–7.1.x, don't trust either vendor's or disclosing party's comfort claim alone; DIVD's own data puts you inside CVE-2026-102490's affected range regardless of the first bug's exploitability.
4. There is no confirmed patch for CVE-2026-102490. Where you can't take the service fully offline, restrict it so the local zammad account can't be a privilege-escalation springboard — least-privilege the service account, and don't run it with unnecessary local shell access.
5. Run DIVD's published log-check script, but treat a clean result as inconclusive, not reassuring — DIVD says so itself.
6. Watch your own helpdesk/ticketing platforms for the behavior pattern above, not just this one product: session-fixation-to-local-root is a chain shape, not a Zammad-specific quirk.

Data as of 2026-10-07live record →