DIVD says an AI agent hacked it. Its evidence is tempo and code comments, and the flaw is still unnamed

Thirteen hours plus eleven hours

On 26 September, two days after saying it had been hacked, the Dutch Institute for Vulnerability Disclosure (DIVD) posted a picture of its intruder's own notes. In the comments of one script, a job is scheduled for 16:00 to 05:00 UTC, which is 13 hours. A second script is described as working 05:00 to 16:00 UTC, which is 11 hours, and as yielding whenever the first is active. Thirteen plus eleven is 24. Between them, the two windows tile the whole day.

What that does not establish. It does not show how long any script ran, or that both did. It does not say who wrote the comments, although DIVD says an AI did. It does not say how the intruder got in, what it read, or when DIVD found it: DIVD has given no date for the first entry or for its own detection. Its statement of 24 September says it took almost seven years to get hacked, and that is the age of DIVD, not the length of the intrusion. DIVD's own site says it was registered as a foundation on 26 September 2019, which puts the statement 2,555 days later, two days short of seven years.

What DIVD has said, in the order it said it

DIVD is a volunteer nonprofit that scans the internet for vulnerable systems and tells their owners. It has put one statement on its own websites and three more posts on LinkedIn. The statement of 24 September is on csirt.divd.nl, the divd.nl newsroom and LinkedIn. The later posts we found only on LinkedIn: when checked at about 17:05 BST on 29 September, the CSIRT blog, its RSS feed and the newsroom carried nothing after the statement. The LinkedIn posts of 24 and 28 September are marked as edited, so the wording below is as displayed on 29 September.

DIVD's public record to 29 September 2026. Sources: DIVD's CSIRT blog, divd.nl newsroom and LinkedIn page, read directly.

Date (2026)	What DIVD said	Where
Thu 24 Sep	It was hacked. It noticed suspicious activity, blocked access to its infrastructure and began forensics with a third party incident response team. The modus operandi 'indicates that this is an agentic AI powered attack'. It assumes breach. It reported the incident to the Dutch data protection authority and the national cyber security centre, and discussed options with the police.	CSIRT blog, divd.nl, LinkedIn
Sat 26 Sep	Two redacted terminal excerpts from its logs. Comments in the scripts explain why the actions are acceptable. 'The AI just got a task and keeps justifying its own actions in the code as comments.'	LinkedIn
Mon 28 Sep	Entry was 'by exploiting a technical vulnerability', 'not Citrix Netscaler', no more detail. The agent decided each next step itself, was sloppy, and over-explained in its comments. No link to known public threat actors or a former volunteer.	LinkedIn
Tue 29 Sep	A separate post distancing DIVD from a former volunteer reported arrested. It does not mention the breach.	LinkedIn
Thu 1 Oct	Promised: the next public update.	28 Sep post

DIVD kept its schedule: the update promised for Monday 28 September arrived that day, and the excerpts came sooner than promised. Four days separate the statement from the update, and three more separate the update from the next. The 29 September post has a separate background. NL Times reported on 28 September the arrest of a man suspected of involvement with the ShinyHunters group in the Odido hack investigation, and said he had volunteered for DIVD. That report does not mention the breach at DIVD, and DIVD's 28 September post says it sees no involvement by a former volunteer. This piece does not connect the two.

Stated and not stated

What DIVD has stated, and what it has not, as of 29 September 2026. Sources: DIVD statement of 24 September and LinkedIn posts of 26 and 28 September. Quotations are DIVD's words.

Topic	Stated by DIVD	Not stated
Detection	It 'noticed suspicious activity, investigated' and concluded it was hacked.	Date of first entry, date of detection, what raised the alarm, how long the intruder was inside.
Entry	'A technical vulnerability' in a system it will not name, 'not Citrix Netscaler'. It has 'a pretty good idea' how they got in.	The product, the flaw, a CVE, a patch state, and whether a person or the agent made the entry.
After access	The agent worked automated on its network, sprayed passwords in a way that polluted its own MITM attack, and wrote over-explaining comments.	Which systems it reached, which accounts it used, how long each phase took, what the MITM job or the spraying produced.
Who was told	'Directly involved parties'. It 'reported the incident' to the Autoriteit Persoonsgegevens (AP) and the National Cyber Security Centre (NCSC), and 'discussed our options with the police'.	Which parties are directly involved, whether a police report was filed, and why the AP was told.
The attacker	'No link to any known public threat actors or involvement by a former volunteer.'	Identity, motive, number of operators, and which AI model, if any, ran the agent.
Data	The worst case is 'a still unknown actor' after its 'crown jewels'. It has 'no facts so far' pointing there, which does not mean it can 'rule it out yet'.	What was read or copied, what the crown jewels are, and whether anything left the network.
Other victims	Once it can share more, it will scan for and notify 'other possible victims, like we always do'.	Whether any DIVD partner or notified organisation is exposed, and what the scan will look for.

DIVD says why it is holding back. Flaw details 'could interfere with the ongoing investigation or cause more victims', and the further log evidence is 'all we can share for now without getting in the way of the investigation'. On the password spraying that polluted the agent's own attack it says only 'More on that later'. Holding a flaw back until affected parties can be told is the coordinated disclosure practice DIVD's own Code of Conduct describes. It is a reason to wait, and it is why nothing here can name the product.

How DIVD concluded it was an agent, and how strong that is

'Agentic AI powered' is a label about how an intrusion was run. It is not a capability level, an actor or a vulnerability, and it can mean three things. The scripts may have been written by a model. The operation may have been driven by a loop in which a model chose each next action. And the target, or the way in, may have been chosen by the agent rather than a person. DIVD's evidence bears on the first two and says almost nothing about the third.

The evidence DIVD cites for an agent, what each piece supports and what it does not establish. Sources: DIVD LinkedIn posts of 26 and 28 September 2026; assessment ours.

Evidence DIVD cites	What it supports	What it does not establish
Comments in the scripts, posted in redacted form on 26 September. They argue the actions are harmless, 'no phishing'.	Model-style authorship: prose written for a reader, explaining why an action is safe.	That a model, rather than a person, ran the scripts. A person who pastes model output gets the same comments.
Tempo and decision pattern: 'after every action it decided the next step itself, at the speed of light'. Logs not published.	A loop in which each action follows from the last result, at machine speed. This is the evidence for autonomy.	Any figure. There are no gaps, counts or session lengths, and only DIVD can check them. A fixed script is also fast; what marks an agent is that each action depends on the last result.
Self-defeating behaviour: password spraying 'polluting its own MITM attack'.	An operator with no plan for the whole operation, which fits an agent working action by action.	The mechanism, which DIVD has held back, or that a person could not do the same.
'Loud and very very messy'.	That the intruder left plenty to reconstruct.	That it was easy to detect in time. DIVD does not say how it was noticed.

Only the first row has anything a reader can look at, and it is two terminal excerpts. The second row is the one that matters for autonomy, and it rests on logs that DIVD holds and we do not. DIVD is a strong witness. Most of its volunteers work in security for a living, it holds the raw evidence, and it thanks the NCSC-NL, Merlon Security and NVISO Security for support. It hedges some wording ('indicates', 'looks like') but states the tempo flatly: 'We could see the agent working automated.' It also drew the line itself, in its own words: 'keep signals we've seen apart from facts we can prove'. Even so, a victim's classification of its own intruder is an inference, and nobody has audited it. The test on 1 October is whether DIVD publishes timings and counts.

Where the coverage went past DIVD. BleepingComputer's report of 29 September is the pointer for this piece and a fair summary. Three of its sentences say more than DIVD's posts do.

Three statements in BleepingComputer's report compared with DIVD's own wording. Sources: BleepingComputer (Bill Toulas), 29 September 2026; DIVD LinkedIn posts.

BleepingComputer says	DIVD's own words	The difference
The intrusion was 'carried out autonomously by an AI agent'.	The modus operandi 'indicates that this is an agentic AI powered attack'.	The report states as fact what DIVD states as an indication.
The threat actor exploited a flaw 'and then used an automated AI agent' after exploitation.	Entry was 'by exploiting a technical vulnerability'. The agent worked automated on its network.	DIVD does not say who or what made the entry, or that the agent came second.
DIVD 'believes that the agent was poorly trained and configured'.	'It also looks like the agent skipped a few steps on its learning curve.'	'Poorly trained and configured' is not in DIVD's posts as we read them.

On interest: DIVD sells nothing and has no product to defend, and its openness here is its own stated policy, so nothing above needs a discount for that. The pull on any victim is to call the intruder dumb. 'Some pretty dumb things' is DIVD's description of conduct, and the excerpts show an operator that planned around its own overlap. It is not a measure of the actor's skill.

Autonomous inside the network is not the same as choosing the network

DIVD's 28 September post lists two scenarios. The worse is that 'a still unknown actor targeted DIVD directly'. The other is 'smash and grab, where an attacker just kicks in the door and takes what they can'. It has 'no facts so far' for the first and cannot yet rule it out. Its 26 September post says 'The AI just got a task', which implies someone or something set one. Who set it, and whether that party picked DIVD or found a door open, is not stated. DIVD's promise to notify 'other possible victims' follows its sentence about the flaw, so it reads as about others who may share it. DIVD does not say so, and it is about who might be vulnerable, not who was attacked.

The distinction changes the defence. An agent that works autonomously once it has a foothold needs a foothold: that is an exposure problem, and DIVD would be one victim among however many share the flaw. A target chosen for what it holds is an identity problem, and the controls that matter are the ones around the data. Our earlier briefing on Gambit's chart of AI harness intrusions shows how far apart the two can be. There, by Gambit's own account, a person chose the targets by filter and typed 1,951 prompts, while the harnesses supplied the tempo. 'Autonomous' described the labour and hid the choice. Nothing yet says which shape the DIVD intrusion had.

What DIVD says it holds, and what it does not say was touched

The irony is plain: an organisation whose work is telling others their systems are exposed has been broken into. What matters is what DIVD says it holds. Its Code of Conduct says its findings 'typically consist of lists with several to millions of IP addresses, the type of vulnerability found, contact information, and metadata', and calls that 'sensitive data'. It stores the data and logs its activity to repeat scans, and it may pass findings on through 'Trusted Information Sharing Partners' such as CSIRTs and internet service providers. Its page on leaked credentials describes handling them at scale, masking passwords when it notifies. Its volunteers are screened and give a certificate of conduct.

None of that is a statement of what sat on the systems the intruder reached. DIVD has not said that any list, credential set or volunteer record was accessed, and has not said what its 'crown jewels' are. This piece does not guess. The general lesson holds whatever the outcome: a list of other people's unpatched systems is a list of targets, and any organisation that runs scans, keeps vulnerability reports or files penetration test findings holds a smaller version of the same thing.

What a detection engineer can take from fast, sloppy, noisy

This is defender guidance built from DIVD's description of a shape of behaviour. It is not a claim about this actor, and each item is a lead to test in your own telemetry, not a rule.

A decision per action. DIVD says each action was followed by a decision about the next, at machine speed. In telemetry that looks like a steady, short gap between many different commands, each depending on the last result, with none of the long idle tails a person leaves. Baseline the gaps for interactive sessions by account and host. Configuration management, CI runners and backup jobs look like this too, so remove them first.

Actions that defeat each other. The spraying that polluted the agent's own attack is a reminder that noise is the detection surface. Two operations on the same targets make failure storms, lockouts, repeated identical requests and retries after errors. An intruder that trips its own tools can be caught, but only if the logs exist and someone reads them. DIVD says it noticed suspicious activity; it has not said what noticed it.

Tooling that explains itself. DIVD's argument is that a person rarely leaves notes in a script arguing it is harmless, and a model does. Newly written scripts with long prose comments, on hosts where administrators do not write scripts, are worth a look. It is a weak signal: your own staff now use coding assistants, and their scripts read the same way.

Windows that cover the day. The posted comments schedule work in a 13 hour window and an 11 hour window. If alerts on internal anomalies are tuned or staffed for office hours, an operator that runs on schedules has the night to itself.

The stop, not only the alert. DIVD blocked access to its infrastructure and began forensics, and has not said how long passed between noticing and blocking. Our briefing on OpenAI's DNS escape is the case for measuring that gap: its monitor raised the alert in 12 minutes, and after a person acknowledged it, stopping the run took another 2 hours 29 minutes.

'Not NetScaler' is an exclusion, not an identification

DIVD says 'it was not Citrix Netscaler'. Our briefing on Citrix's eight NetScaler flaws covers the bulletin of 27 September, in which Citrix reports exploitation of two. DIVD's sentence rules NetScaler out for its own incident. It does not make NetScaler less urgent for anyone else, and it names nothing to patch instead. DIVD does not say why it named NetScaler at all. The timing is ours to note, not DIVD's to confirm: the bulletin came on 27 September and the DIVD post on 28 September, so the exclusion may have been meant to stop a guess spreading. That is inference.

What to do, in the order worth doing

DIVD's own guidance says its notification emails come from an address at divd.nl, in the forms csirt@divd.nl, a case number at csirt.divd.nl, or a researcher's name at divd.nl, and that the case status is on the CSIRT site. On the UK side, if personal data may be involved in an incident of your own, the ICO says you must tell it 'as soon as possible, and where feasible within 72 hours' when a risk to people is likely. DIVD reported to the Dutch regulator; it has not said whether personal data is involved.

What would change this on 1 October

Read DIVD's update against five questions. Does it publish timings or counts behind 'decided the next step itself'? Does it say whether a person or the agent made the entry? Does it name a product or a CVE, or the class of flaw? Does it give a date for first entry and for detection, and the time from detection to isolation? Does it say what data, if any, was reached? Each answer would move a row of the table above from 'not stated' to stated, and this briefing would need updating.

The question that exposes the gap

Most of DIVD's volunteers work in security for a living. The intruder wrote its own notes and tripped its own tools, and five days after its first statement the public record still has no dates, no flaw and no data outcome. If an intruder that loud and that messy reached your network tonight, which of your logs would show its rhythm, and who could cut it off at three in the morning?

Key facts