DIVD’s Intrusion Trail Did Not Settle the Damage
An intruder’s mistakes can be useful evidence. They are not a reason to assume the damage was small.
In its public account reviewed on 29 September, the Dutch Institute for Vulnerability Disclosure described an agent choosing successive actions rapidly and leaving explanatory comments that helped investigators. It said the agent mixed password spraying into its own interception activity. The entry flaw was then undisclosed, but Citrix NetScaler was excluded.
That post distinguished observations from scenarios: the organisation had no facts pointing to a targeted attempt to obtain its most sensitive material, but could not rule it out. This was a dated assessment, not a description of the subsequently confirmed losses. The public post is marked edited; its original publication timestamp does not establish when each passage changed.
The current incident case identifies Zammad as the entry point. The actor exploited two flaws, obtained root and then used AI agents for further activity. This sequence does not demonstrate independent discovery of the flaws or an end-to-end attack without human direction. The operator, model and supervision remain publicly unresolved.
What the later data findings establish
The 9 October update confirms stolen volunteer email addresses; contact details may have been taken. Affected people are still being identified; impersonation and social-engineering risks increase.
Preliminary signs of partial exfiltration cover the GSuite office environment, IT support systems, the helpdesk included, Jira/Confluence and operational systems. HR, Slack and source-code repositories showed no intrusion evidence, not an all-clear.
The CSIRT mailbox held conversations and replies, not initial notifications; only part was extracted. Correspondents should assume their exchanges may be held: follow-up requests with vulnerable-system IP addresses, vulnerability reports and masked credential-dump extracts. The separate environment for vulnerability records and numbering showed no indication of access. Investigations and final assessments remain unfinished, without a final affected-party count.
Separate the two flaws and their patch paths
The original vulnerability case describes two zero-days. With a stolen session, CVE-2026-102489 can run attacker-chosen code under the zammad account. Exploitable builds are 6.3.0 through 6.5.4. The defect persists in 7.0.0 through 7.1.3, but the runtime conditions prevent exploitation there. Its log-check script is an investigation aid, not proof that a clean installation was never exploited. BlackTree has not run it.
The vendor’s 5 October assessment likewise says 7.0 and later are not affected in practice and identifies 7.2.0 as additional hardening. Its local-escalation assessment requires a prior server foothold, not remote exploitation on its own. Earlier uncertainty about a fix has since been superseded by a specific release.
CVE-2026-102490 lets a local zammad account reach root. The current package advisory identifies DEB/RPM installations through 7.2.1 as affected and 7.2.2 as fixed. Source installations and official container images are outside that affected package set. A successful application update must therefore be checked against the actual installation method, not just a deployment job’s status.
The 8 October release notice calls for self-hosted upgrades and says hosted customers need no action. The separate 15 October emergency release supplies 6.5.5 hardening against the session flaw for the unsupported 6.5 branch. It requires migration to a new package repository before updating. This temporary measure does not extend support; the vendor recommends a prompt move to 7.2.2.
Known exploitation requires evidence-led triage
The current federal exploited-vulnerability catalogue retains both flaws, says they can be chained and requires forensic triage. Ransomware use is listed as unknown. Both entries retain a due date of 5 October 2026; that federal requirement is not a universal deadline for every organisation. Assess each asset’s internet exposure and preserve relevant evidence.
Isolation came before certainty
The initial disclosure on 24 September described suspicious activity, confirmed compromise, blocked infrastructure access and forensics with an external response team. Directly involved parties, the Dutch data protection authority and NCSC-NL were informed; options were discussed with police. Handling the incident as a worst case 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. Reconstruct the sequence: what information became available, which identity acted, what changed and what followed a failure.
A failed command need not end an attempt. Look for retries, alternative routes and activity through other identities. Treat apparent mistakes as leads to test, not proof of incompetence or a particular model.
Contain active compromise while preserving evidence where safe. Revoke compromised sessions and tokens, disable implicated identities and coordinate isolation. Do not delay necessary containment for 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 where feasible. Record collection times and gaps so an absent event can be distinguished from missing telemetry.
Separate an intruder’s comments from independently observed effects. A claim of success does not prove 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 incident assessment
BlackTree’s earlier report on a framework managing 23,800 stolen secrets concerned a separate case. It offers context, not evidence of a connection to this incident.
Establish what was reachable, what happened and whether access is closed. An explanation of attacker behaviour should sharpen those questions, not replace the answers.
Source check: 21 October 2026. The linked primary statements and vendor notices retain their distinct dates and scopes; modification times are not proven first-publication times. The catalogue checked was version 2026.10.21, released at 14:04:39 UTC. The original publication date and URL of this article are unchanged.
