Labs
Close

Loud, messy, and root in seconds

The agent that breached DIVD commented its own scripts, broke its own man-in-the-middle, and still went from a hijacked helpdesk session to root before anyone could read the logs. It did not need to be good.

2zero-days chained
secondssession to root

On September 21 the Dutch Institute for Vulnerability Disclosure was hacked. DIVD is a volunteer nonprofit whose entire job is scanning the internet for exposed systems and warning their owners, which makes it roughly the last organisation you would expect to find on the wrong side of a disclosure. Their own case page is titled When, not if, and it is to their credit that they published the details.

The attacker was an AI agent. DIVD said so first, and Sysdig's analysis this week lays out why: the chain was not pre-planned, each step was chosen after the last at machine speed, and the scripts it dropped were commented the way a model comments code, including reassurances to itself like "no phishing" and "no spam." At one point its own password spraying knocked over the man-in-the-middle it was running. DIVD's words for the operation were "loud and very, very messy."

It got root anyway.

The chain

The way in was Zammad, the open-source helpdesk DIVD used for csirt@divd.nl. Two bugs, neither public at the time:

  • CVE-2026-102489. A session hijack that leads to remote code execution as the zammad service user. Exploitable on 6.3.0 through 6.5.4, which were already out of support. Present but not exploitable on 7.0 to 7.1.3.
  • CVE-2026-102490. A local privilege escalation from the zammad user to root. Every version DIVD tested, including the current alpha.

Chained, the pair scores 9.4, and the time from hijacked session to root was, per DIVD, seconds. Zammad has since fixed both, the first in 7.2, and says it had received a report on CVE-2026-102489 in August, before the breach. DIVD analysed and reproduced the bugs on the 22nd and 23rd, reported them on the 24th, and by the 26th was scanning the internet for other vulnerable instances and warning their owners. Which is to say: the victim ran the disclosure.

Two things worth sitting with

The first is that this attacker was bad at its job and it did not matter. A human operator who tripped over their own tooling, left narrated scripts on disk and sprayed passwords loudly enough to break their own session would be an embarrassment to whoever hired them. The agent did all of that and still exfiltrated data, because it was fast and it did not stop. Sysdig's phrasing is the right one: an agent will do what it takes to complete the task regardless of the mess, and the mess is where your detection lives. A Rails worker spawning a shell, a session reused from a new address seconds after login, a root-owned child under the Zammad process tree — every one of those was visible, in real time, to anyone looking.

The attacker did not need to be good. It needed to be faster than the time it takes a person to open the logs.

The second is about the bugs themselves. One of them had already been reported to the vendor. The other was in every version ever shipped. Neither needed a frontier model to find; they needed someone to point a capable loop at a widely deployed helpdesk and let it run. The agent that did so was not sophisticated. It was simply the first to look.

What we take from it

We spend our days running agents against customer applications, with permission, and the DIVD write-up reads like the mirror image of our logs. Same non-determinism, same step-by-step reasoning, same willingness to try the obvious thing. The difference is the harness around it and whose side it is on.

The practical lesson is not "AI attackers are coming." They are here, and this one was mediocre. The lesson is that the gap between a bug existing and a bug being exploited has closed to the point where a vulnerable helpdesk on the public internet is already a breach with a short delay. If an agent on the other side can find the chain in your software, an agent on your side should have found it first. That is the whole bet.

DIVD got that part right too. Their case page's first line, after the title, is that they are investigating and will publish what they learn. Two weeks later they had scanned the internet for everyone else's exposure and told them. Loud and messy on the way in; clean on the way out.


Sources: DIVD's case pages DIVD-2026-00014 and DIVD-2026-00015, Sysdig's AI agent exploits Zammad zero-days in DIVD breach, and BleepingComputer's report.