DIVD Says Its Intruder’s AI Agent Left a Trail Investigators Could Follow
An intruder’s mistakes can be useful evidence. They are not a reason to assume the damage was small.
In a public update reviewed on 29 September, before DIVD identified the entry point, the Dutch Institute for Vulnerability Disclosure said an intruder exploited an undisclosed technical flaw, excluding Citrix NetScaler. DIVD described an automated agent choosing successive actions rapidly, mixing password spraying into its own interception activity and leaving comments useful to investigators.
Zammad is now identified as the entry point. The operator, model and level of human supervision remain unresolved publicly.
Update, 1 October: DIVD confirms some data left its systems
DIVD’s data-investigation overview confirms that volunteer email addresses were exfiltrated and says contact details may also have been taken. It is still determining which volunteers are affected and warns that the exposure may enable more convincing impersonation and social engineering.
DIVD says the CSIRT ticketing system contained mailbox conversations and replies, but not its initial notifications. It says the attacker extracted only part of that material. People and organisations that corresponded with the CSIRT should nevertheless assume those exchanges may have been obtained. Possible material includes follow-up requests with vulnerable-system IP addresses, vulnerability reports and masked credential-dump extracts. This warning reflects uncertainty, not confirmation that every ticket or every listed category was taken.
Other systems and data categories remain under investigation. The overview gives no final affected-party count or categorical all-clear.
In its September update, DIVD said it had no facts supporting its worst-case scenario but could not exclude it. That was the organisation’s position at the time, not a current description of the 1 October findings.
Update, 1 October: Zammad flaws enabled the breach
DIVD’s case identifies two Zammad zero-days. CVE-2026-102489 allows session hijacking and code execution as the zammad user. It lists 6.3.0 through 6.5.4 as exploitable; 7.0.0 through 7.1.3 also contain it, but environmental conditions prevent exploitation there.
CVE-2026-102490 lets the local zammad user escalate to root. The table lists 1.5.0 through 7.1.0-alpha, while the summary says all versions, including the latest alpha. That range remains unclear.
Update, 2 October: CISA adds both flaws to KEV
CISA’s Known Exploited Vulnerabilities catalogue now includes CVE-2026-102489 and CVE-2026-102490, which CISA says can be chained. Both entries require forensic triage, list ransomware use as unknown and give 5 October as the catalogue due date. BlackTree could not access the linked BOD 26-04 pages during this check, so that date is not presented as a universal deadline.
In a later 1 October update, Zammad said it had received details for CVE-2026-102490 and was working on them. Zammad says the flaw cannot be exploited remotely on its own because an attacker already needs server access. The affected range and fixed release remain unverified.
For CVE-2026-102489, Zammad says exploitation is possible only on 6.5 and older; 7.0 and later are not affected in practice. It says hardening is included in 7.2.0 and recommends updating to 7.2.0, without identifying it as a first fixed release. For CVE-2026-102490, follow Zammad’s security advisories while work continues. Assess internet exposure and preserve relevant evidence. DIVD’s log-check script for CVE-2026-102489 remains available. BlackTree has not run it; a clean result would not establish that either flaw was unexploited.
This does not establish that AI independently discovered or exploited the entry flaw. BleepingComputer’s 29 September report describes automated post-exploitation activity, not evidence of an independently verified end-to-end autonomous attack.
Isolation came before certainty
DIVD’s initial disclosure on 24 September said it had detected suspicious activity, confirmed a compromise, blocked infrastructure access and started forensics with an external incident-response team. It notified directly involved parties, the Dutch data protection authority and NCSC-NL, and discussed its options with police.
The organisation was treating the incident as a worst-case scenario while investigating. That was a response posture, not a finding about stolen information.
The useful question is what happened between actions
BlackTree analysis: Speed alone is a poor AI detector. Scripts and human-operated frameworks can also work quickly. A useful investigation reconstructs the sequence: what information became available, which identity acted, what the action changed and what followed a failure.
That sequence matters because a failed command is not necessarily the end of an attempt. Responders should look for retries, alternative routes and activity through other identities. Treat apparent mistakes as leads to test, not proof of either the attacker’s incompetence or a particular model’s involvement.
During active compromise, contain access while preserving evidence where safe. Revoke compromised sessions and tokens, disable affected identities and isolate implicated systems in a coordinated response. Do not delay necessary containment to obtain a perfect forensic record.
Collect high-resolution timestamps, process trees, identity events, command histories, network flows and relevant cloud logs. Preserve temporary files and automation artefacts when feasible. Record collection times and gaps so later analysis can distinguish an absent event from missing telemetry.
Most importantly, separate an intruder’s comments from independently observed effects. A comment claiming success is not proof that a command ran, a file was read or data left the network. Match it against host, identity and network evidence.
Do not let the AI label replace the incident assessment
BlackTree’s earlier report on an agentic attack framework managing 23,800 stolen secrets examined a separate case. It provides context, not evidence of a connection to DIVD.
The operational test remains familiar: establish what was reachable, what actually happened and whether access is closed. A colourful explanation of attacker behaviour should sharpen those questions, not become a substitute for answering them.
Sources
- DIVD CSIRT initial disclosure, 24 September 2026.
- DIVD public incident update, reviewed on 29 September. The edited post exposes a relative timestamp, not an exact publication or edit time.
- BleepingComputer’s reporting, 29 September 2026.
- DIVD Zammad vulnerability case, last modified 1 October 2026 at 13:27 CEST; DIVD incident case, last modified 1 October 2026 at 14:59 CEST; and DIVD data-investigation overview, observed 1 October 2026. Modification times are not proven first-publication times.
- CISA KEV catalogue JSON, version 2026.10.02, released 2 October at 15:19:38 UTC and first observed by this monitor at 23:12 CEST.
- Complete Zammad community topic JSON, including the core-team updates of 1 October at 12:16:59 UTC and 19:48:04 UTC.


