AI Agent Breached Bug-Hunting Nonprofit DIVD by Chaining Two Zammad Zero-Days

On 21 September 2026 an attacker broke into the Dutch Institute for Vulnerability Disclosure (DIVD), the volunteer-run nonprofit that spends its days warning other organisations about exposed and vulnerable systems. The way in was the organisation's own helpdesk: two zero-day flaws in Zammad, the open-source ticketing system, chained from a hijacked session to root on the server in seconds.

The attacker was an AI agent, DIVD says, and not a careful one. "This is an attack we have not seen before. Not because it's our first, but because the modus operandi indicates that this is an agentic AI-powered attack," the group wrote when it first went public. It described the intrusion as "loud and very very messy".

DIVD published the technical details on 1 October as case DIVD-2026-00015, with the two CVE ids, the affected versions and a script to check Zammad logs for signs of exploitation. Its advice to every Zammad operator is short: upgrade to Zammad 7, or take the system offline.

What happened

The timeline below comes from DIVD's case file and its statements to the press.

• 21 September: the agent exploits the two Zammad flaws and gets into DIVD's infrastructure.
• 22 September: DIVD spots the activity and blocks access to its data centre. It brings in an outside forensics team and notifies the police, the Dutch data protection authority (Autoriteit Persoonsgegevens) and the National Cyber Security Centre (NCSC).
• 22–23 September: DIVD analyses and reproduces the exploit chain.
• 24 September: DIVD reports both flaws to Zammad.
• 26 September: DIVD starts scanning for exposed Zammad instances, makes a limited disclosure and notifies other victims.
• 29 September: BleepingComputer reports the breach. DIVD has not yet named the flaw, beyond saying it was not Citrix NetScaler.
• 1 October: full public disclosure, with the CVE ids, the case file and the log check script.

Ten days from the break-in to full disclosure. Source: DIVD case DIVD-2026-00015, The Register, BleepingComputer.

From Zammad, the agent moved on to other services and took data before segmentation stopped it. The Register reports that the stolen data belongs to DIVD's volunteer researchers: their DIVD email addresses and possibly other contact details. DIVD says the scope stayed limited "thanks to proper network segmentation and the actions of its IT and incident response team after detection", and it has promised a separate account of exactly what was taken.

The two Zammad flaws

Neither flaw is enough alone. CVE-2026-102489 gets an outsider code execution as the unprivileged account Zammad runs under. CVE-2026-102490 turns that account into root. Chained, they hand an unauthenticated attacker the whole server, and the agent ran the chain in seconds.

Only Zammad 6.3.0 to 6.5.4 is open to the remote half of the chain; the root escalation reaches back to 1.5.0. Source: DIVD-2026-00015, Zammad.

Why DIVD thinks it was an agent

DIVD points to how the intrusion behaved, not to any signature. In its words, "the agent worked automated, deciding next steps itself at high speed", with "sloppy logic or pattern". It also "has done some pretty dumb things, like polluting its own MITM attack with password spraying", running a noisy credential attack through the same channel it was trying to intercept quietly.

The giveaway was the commentary. "The agent is so overexplaining in its comments that it makes our job in reverse engineering a lot easier," DIVD said. The scripts left behind were full of self-justifying notes explaining why each step was taken. A human operator does not usually write those.

That cuts both ways. A messy, badly configured agent still found and chained two unknown flaws in a widely deployed helpdesk and reached root on the first try. Its sloppiness made the forensics easy, but it did not stop the break-in. What stopped it from going further was network segmentation, which is an ordinary control.

It also fits a pattern TF has been tracking. In July, Sysdig documented JadePuffer, an extortion campaign that a language model ran from exploitation to data destruction. DIVD is the first case TF has covered where the agent's way in was a pair of zero-days rather than a known CVE.

Patch status: read the vendor and DIVD together

The two sides do not yet describe the fix the same way.

• DIVD says Zammad 7 is safe from the chain it saw exploited, and tells users to upgrade to it or go offline.
• Help Net Security reported on 1 October that "both flaws are currently without a fix".
• Zammad posted on its community forum on 1 October. On CVE-2026-102489 it said "Zammad 7.0 and later are not affected" and that the change is included in Zammad 7.2.0, the current stable release. On CVE-2026-102490, it first said DIVD had not yet given it technical details. Later the same day, after receiving them, it said the issue "cannot be exploited remotely on its own" because an attacker would already need access, and again told users to update to 7.2.0.
• As of 2 October, Zammad's GitHub security advisories list no entry for either CVE.

In practice: Zammad 6.5 and older are end of support and fully exposed to the remote half of the chain. Version 7.x blocks that remote entry point, and 7.2.0 is the release both sides point to. The root escalation is still worth treating as live on any server where an attacker might already have a foothold.

What Zammad operators should do now

1. Find every instance. That includes forgotten test and staging helpdesks, which are the likeliest to still run 6.x.
2. Save your logs before you touch anything. The Dutch NCSC's advice is to secure application and network logs before patching, so that you can still investigate a compromise during the zero-day window.
3. Run DIVD's IoC check script (cve-2026-102489_ioc_check_script_v2.sh, linked from case DIVD-2026-00015) against your Zammad logs.
4. Upgrade to Zammad 7.2.0. If you cannot do that today, take the instance off the internet until you can.
5. If the script finds anything, assume root. Treat the host as fully compromised: rotate every credential the helpdesk could see (mail connectors, LDAP/SSO bindings, API tokens, integration keys) and rebuild rather than clean.
6. Segment the helpdesk. A ticketing system faces the internet by design and holds customer data. It should not have a route to the rest of your network, and DIVD's own segmentation is why this breach stayed small.
7. Watch for the follow-up. Zammad has said it will publish GitHub security advisories, and DIVD has promised a breakdown of the stolen data.

The bigger point

DIVD runs on volunteers and has spent years warning other organisations about exposed systems. Its own write-up was titled "It was a matter of when, not if". The lesson for everyone else is not that agents are clever. This one was clumsy. The lesson is that an agent working at machine speed only needs one internet-facing application with an unknown bug, and every self-hosted helpdesk, wiki and ticketing tool is that application. Patch quickly, keep logs where an intruder cannot reach them, and assume the next agent will write fewer comments.

Sources

• DIVD: It was a matter of when, not if
• DIVD CSIRT: case DIVD-2026-00015, Zammad vulnerabilities
• Zammad Community: Local Privilege Escalation (CVE-2026-102490) reported as actively exploited
• Help Net Security: AI agent used Zammad zero-days to breach Dutch vulnerability disclosure non-profit
• The Register: AI agents hacked the hackers, stealing email addresses from security research org
• SecurityWeek: Zammad zero-days exploited in AI-powered DIVD hack
• BleepingComputer: Automated AI agent used to breach cybersecurity nonprofit DIVD
• BleepingComputer: DIVD says Zammad zero-days enabled AI-driven network breach
• Security.NL: Zerodaylekken in ticketsysteem Zammad gebruikt bij hack van DIVD