On 21 September, the people who find vulnerabilities for a living got hacked: DIVD, the Dutch nonprofit of volunteer researchers, fell in seconds to what it describes as an autonomous AI agent. I run AliasFleet, an email-alias service where one leaked address names its leaker and dies on contact. That is the lens I read this breach through.
The confirmed theft is small and specific: volunteer email addresses, and possibly contact details.
Small, and exactly the kind of theft that keeps working for years.
How the break-in worked
The entry point was DIVD's own helpdesk software, Zammad. DIVD's forensics found two zero-day flaws and chained them: CVE-2026-102489 turns a hijacked session into remote code execution as the Zammad user, and CVE-2026-102490 escalates that user to root. DIVD assigned both CVE numbers itself; it is a CVE Numbering Authority. Its statement puts it plainly: the attackers went from session hijack to root "in seconds due to the agentic part of this hack." The chained score is CVSS 4.0 9.4, critical. The full timeline runs from first access on 21 September to confirmed exfiltration disclosed on 1 October.
Then the part that made this story travel. DIVD says the attack was "loud and very very messy", with the agent deciding each next step itself at machine speed, using sloppy logic. Its scripts contained comments where the agent justified its own actions, explaining why what it was doing was okay and really not phishing. BleepingComputer's writeup adds that the agent did "some pretty dumb things", including interfering with its own man-in-the-middle activity by password-spraying at the same time. A human attacker would not bother writing apologies into attack scripts. This one did, because nobody was driving.
One thing to keep straight: the AI-agent claim is DIVD's assessment based on how the attack behaved, not independently confirmed proof. And Zammad's own 1 October community statement reportedly disputes the scope, saying the first flaw only affects version 6.5 and older (per the Windows Forum writeup of Zammad's statement); DIVD's position is that it is present but not exploitable in newer versions for environmental reasons. That disagreement is unresolved. The one undisputed fact is the US government's: CISA put both CVEs in its Known Exploited Vulnerabilities catalog on 2 October, with remediation due 5 October.
What the attackers took
DIVD's own words, from its data investigation page: "We know for sure that volunteer data got out, such as DIVD email addresses and possibly contact details." Whose data and exactly which data is still being investigated. There is no victim count, and this piece will not invent one.
Beyond that, DIVD says to assume the worst about its CSIRT mailbox: if you ever emailed back and forth with its incident-response team, the attackers may have those threads. That could include follow-up scan data, reported vulnerabilities, and extracts of credential dumps with masked passwords. DIVD also notes the attacker "had to work for every bit of data they got out", so the exfiltration was partial. Its accounting and bank systems are handled by an external party, with no sign of compromise. And nobody, DIVD included, claims passwords or payment data were taken. Do not let anyone tell you they were.
DIVD is not in Have I Been Pwned as of this writing, so there is no easy self-check yet.
Why a stolen address list is a weapon
Read DIVD's own consequence line slowly: "it does mean it's now easier for someone to pose as a DIVD volunteer."
These are not random Gmail accounts. They are the addresses of trusted security researchers, inside a trust network where people routinely receive alarming emails about vulnerabilities and are expected to act on them. An attacker who can write from, or convincingly as, one of those addresses can ask a company to "confirm" details, request log files, or steer someone to a malicious link. The request arrives wearing a trusted name. The Dutch data-protection authority and the national cyber security centre were notified on 24 September, which tells you how seriously this is taken. But no authority can un-send an address list.
This is also why DIVD's own guidance is the right first move for everyone else: "If a message from someone at DIVD feels off, check with us first at communications@divd.nl." Out-of-band verification. Do not reply to the suspicious message. Open a fresh channel.
What to do now
If you are a DIVD volunteer, a correspondent, or you run Zammad, do these in order.
1. Treat any DIVD-flavoured message as untrusted until verified. Verify through a separate channel before clicking or replying, exactly as DIVD asks. Impersonation is the stated risk of this breach, not a hypothetical.
2. If you emailed DIVD's CSIRT back and forth, assume the thread is exposed. Rotate any credentials, tokens, or internal addresses that appeared in those conversations. Treat any follow-up "scan data" or "credential dump" message claiming to come from DIVD as hostile until proven otherwise.
3. If you run Zammad, inventory every instance today. Preserve application and network logs before you update; the Dutch NCSC explicitly advises this. Then upgrade to Zammad 7 (the vendor currently points to 7.2.0) or take the instance offline, run DIVD's log-check script for indicators of compromise, and rotate credentials and API tokens the helpdesk host could reach. The Register's coverage has the full background.
4. Watch your own inbox for the second wave. Breaches like this one, like the Medela breach, convert stolen contact data into spear phishing over the following months. The longer checklist lives in our breach response guide.
The part you actually control
Here is the uncomfortable bit. DIVD assumes breach, segments its network, and responds to incidents professionally. It did everything right on paper, and still lost its volunteers' addresses to a helpdesk zero-day chained by a sloppy robot in seconds. Your address is only as safe as the worst software in your counterparty's stack, and you will never see any of it.
So stop trying to vet your way out. Make every address you hand out cheap to burn instead.
That is what an email alias is: a separate forwarding address per site, per contact, per purpose, that you can pause or kill the day it shows up somewhere it should not. Had each address on DIVD's list been a unique alias, the stolen list would name its own thief and die on contact, instead of real identities going into someone else's phishing rotation. I run AliasFleet, which does exactly this: one alias per site, killable in one click, with the free tier covering 10 active aliases. The mechanics are in our guide on what an email alias is. For the tracing side, see which website leaked your email.
An alias would not have stopped the break-in. Nothing a victim does stops the theft itself. What it does is make the stolen goods worthless, which is the only revenge available to the rest of us.
Top comments (0)