DIVD was breached through two Zammad flaws. One has no fix on record, and the AI claim is no stronger

Ten days from first access, and one flaw with no fix on the record

DIVD's case file dates the first access to its systems to 21 September 2026. Today, 1 October, is day 10. DIVD reported the flaws to Zammad on day 3, 24 September. Zammad's newest release, 7.2, is dated 23 September, a day before that report, and as of 11:55 BST today we found no Zammad advisory or release that names either flaw. The Dutch national cyber security centre (NCSC-NL) says the second flaw is not fixed.

What that does not establish. It does not show that no fix is coming: DIVD's case file says Zammad is 'working on a fix'. It does not show that anyone other than DIVD has been breached, because DIVD is the only victim named in any source. And it does not show that an AI agent ran the intrusion, or that one did not. Our briefing of 29 September recorded that DIVD's evidence for an agent was tempo and comments in scripts, and that it had not named the flaw. It has now named the flaw. That changes what a defender should do today. It does not change the evidence for an agent.

What changed since our first briefing

Our first briefing ended on a list of things DIVD had not said. Several have moved, and the movement is about dates and one named product. The rows that matter most for the AI claim have not moved. DIVD published the root cause a day ahead of the update it had promised for 1 October, and says its overview of compromised data is planned for today.

What moved between 29 September and 1 October. Sources: DIVD case files DIVD-2026-00014 and DIVD-2026-00015, DIVD's LinkedIn post of 30 September, and our briefing of 29 September.

Question	On 29 September	Now on the record
The flaw	'A technical vulnerability', 'not Citrix Netscaler'. No product.	Two zero-days in Zammad, CVE-2026-102489 and CVE-2026-102490, found by DIVD and Merlon Security while investigating the breach. Still open: how the intruder got them.
First entry and detection	No dates.	First access 21 September. On 22 September DIVD 'becomes aware' and blocks access to all systems in its datacenter. Still open: times of day, and what raised the alarm.
Who fired the chain	Not stated.	Still not stated. DIVD says 'the attackers' chained the flaws 'in seconds, due to the agentic part of this hack'.
Data	'No facts so far' for a targeted raid. Assume breach.	Attackers could 'access other services and read and exfiltrate data'. Still open: which data and whose. Overview planned for 1 October.
Other victims	DIVD will notify 'other possible victims'.	DIVD scanned for exposed Zammad instances on 26 September and began notifying owners. Still open: any count, and any second compromise.
Evidence for an agent	Tempo, comments in scripts, unpublished logs.	The same, plus the word 'seconds'. No log, timing or count.

The chain, as the records describe it

Two CVE records, both assigned and scored by DIVD itself as a CVE numbering authority, describe the chain at the level a defender needs. DIVD has withheld the mechanism: both records are titled 'Undisclosed'. This briefing goes no further than they do.

The two flaws as DIVD's CVE records and case file describe them. Sources: CVE.org records (assigner DIVD), NVD, case DIVD-2026-00015. All scores are CVSS 4.0 and all are DIVD's.

Item	CVE-2026-102489	CVE-2026-102490
What DIVD calls it	Session hijack leading to remote code execution as the zammad user.	Escalation from the local zammad user to root.
Reach in its own vector	Network, no privileges, 'passive' user interaction.	Local, low privileges, no user interaction.
Versions in DIVD's prose	6.3.0 to 6.5.4 exploitable. 7.0.0 to 7.1.3 'present' but 'not exploitable due to environment conditions'.	'All versions of Zammad including the latest alpha'.
Versions in the structured record	6.3.0 up to, not including, 6.5.4 affected. 7.0.0 and later 'unaffected'. Earlier than 6.3.0 'unknown'.	1.5.0 up to, not including, 7.1.0-alpha affected. Earlier than 1.5.0 'unknown'.
Score on its own	8.7 High.	8.5 High.
Score as chained	9.4 Critical.	9.4 Critical.
Score NVD and NCSC-NL print	9.4.	9.4.
Fix on the record	DIVD: 'Upgrade to Zammad version 7'. No Zammad advisory found.	None. NCSC-NL: not fixed for now.

Read the scores with care. The 9.4 beside CVE-2026-102490 on NVD and in the NCSC-NL advisory is the score for the chain, which describes a flaw reachable over the network with no privileges. On its own the flaw is local and needs a low-privilege foothold, and DIVD's record scores that 8.5. A queue sorted by the NVD figure would rank the escalation flaw as a remote bug. It is no less urgent, because the first flaw supplies the foothold, but it changes which of your systems you think are exposed. NVD has not analysed either record (its status is Deferred), so every score is DIVD's. DIVD is the victim, the finder, the numbering authority and the scorer. That is normal for a CNA and not a criticism, but nobody independent has yet checked any of it. Our briefing on two scores per flaw covers how the choice of number travels.

Read the version lists with care too. Prose and structured data disagree in three places. The prose puts the first flaw in 6.3.0 to 6.5.4, while the structured record stops before 6.5.4. The prose says version 7 is affected but not exploitable, while the structured record says it is unaffected. And the prose says the second flaw is in every version including the latest alpha, while the structured record ends before 7.1.0-alpha, although Zammad's repository has a tag for 7.3.0-alpha. Follow the wider reading, as DIVD's case file and NCSC-NL (in our translation, 'all common versions') do.

Two details in the vectors matter to a defender. 'Passive' user interaction is defined by FIRST as a limited, involuntary action by a user of the vulnerable system. DIVD has not said what the action is, and it is the one hint about what the first flaw needs from a victim. And both flaws are marked 'Automatable: Yes', which FIRST defines as attackers being able to automate all four steps of the kill chain reliably, from reconnaissance to exploitation. That is a property of the flaws, whoever or whatever runs them.

Was it a zero-day on the day?

Yes, by DIVD's own dates, and for one of the two flaws it still is. A zero-day, in the usual sense, is a flaw exploited before the vendor has a fix and often before it knows. DIVD says the flaws were abused on 21 September, analysed and reproduced on 22 and 23 September, and reported to Zammad on 24 September. Zammad's last advisories before that were dated 25 August. So on day 0 nothing on any public record described either flaw. What the dates cannot say is when Zammad learnt of them, because Zammad has published no account of its own.

The flaw is older than the breach. DIVD lists 6.3.0, released on 17 April 2024, as the earliest affected release for the first flaw. That is 887 days before 21 September 2026, and releases before 6.3.0 are marked 'unknown', not safe. The second flaw is listed from 1.5.0, released on 21 April 2017. Those are the release dates of the first affected version DIVD names. They are not dates anyone found the flaws, and they are not evidence that anyone used them earlier. They are the reason the log search below starts at the beginning of your logs and not on 21 September.

Day 10 and the second flaw. Zammad's newest release is 7.2.0, dated 23 September. Its notes describe an audit log, spam protection and AI features, and it predates DIVD's report by a day, so it cannot be a response to it. The newest security release is 7.1.3 of 25 August, and Zammad's GitHub security advisories, where it says its advisories now go, end the same day. There has been no 6.5 security release since 6.5.4 on 8 April, which we derive from the release list and Zammad has not stated. NCSC-NL says Zammad has released updates for the first flaw and that the second is not fixed. The page it links under a label that translates as 'read the advisory of Zammad' is NCSC-NL's own advisory, and we could not match its 'updates' to a Zammad release. DIVD's case file says both 'patch status: available' and that Zammad is 'working on a fix'.

What the root cause says about the AI claim

'An AI agent hacked it' bundles three claims, as our first briefing set out: scripts written by a model, an operation steered action by action by a model, and a target or entry chosen by one. The Zammad finding is about a fourth thing, how the door was opened. It moves none of the three directly.

What the Zammad record establishes and does not establish about the AI claim. Sources: DIVD case files, CVE.org records, DIVD's LinkedIn post of 30 September. Where a cell says 'inference' it is ours.

Question	The record establishes	It does not establish
How was DIVD entered?	Through two software flaws in Zammad: session hijack, code execution as the zammad user, then root.	The mechanism, which DIVD has withheld, or whether a person or the agent fired the chain.
Could a person have run this chain?	Each step is a standard class, and both flaws are scored 'Automatable: Yes'. Inference: a person with ordinary tooling could run it.	That one did. DIVD has not said so, and its reading of its logs is that an agent decided each step.
Is 'in seconds' evidence of an agent?	DIVD says the chain ran 'in seconds, due to the agentic part'.	Any timing, log or count. A pre-written chain is also fast. What marks an agent is a decision after each result.
Who had the two flaws on 21 September?	They were unpatched and, on DIVD's dates, unreported to the vendor.	Who found or obtained them, and whether a model did. This is the costly part of the operation, and the record is silent.
Did a model write the scripts?	Nothing new. The comments DIVD posted on 26 September stand, in part.	Authorship, or whether the comments explain the exploitation steps.

The verdict, and it is an inference. Nothing in the primary sources makes the agent claim better supported than it was on 29 September, and nothing makes it worse. The root cause answers 'how did it get in'. The agent claim answers 'how was it run'. They are independent, and a person could have run the chain too. What the root cause changes is what is worth asking. An operator that held two working Zammad zero-days on 21 September had either done serious research on a mature open-source product or obtained that work from someone who had. DIVD's post of 28 September also describes that operator as sloppy, spraying passwords that polluted its own attack and over-explaining in its comments. The two descriptions sit uneasily. One reading that fits both, and it is only a reading, is that the chain was supplied and an agent was the hands. If so, 'AI-driven' describes the tempo and not the capability, and the capability that mattered, the two flaws, came from somewhere the record does not name.

That is also where the targeting question from our briefing on Gambit's intrusion chart returns. There, 'autonomous' described the labour and hid the choice of target. Here, an intruder that held two Zammad flaws before the vendor knew may have attacked every exposed Zammad it could find, or DIVD in particular. NCSC-NL says the flaws have been exploited since at least 21 September (our translation) and names no victim but DIVD, so that date is DIVD's own first-access date and not a second sighting. DIVD's two scenarios, a targeted raid and a smash and grab, are both still open.

Interests. DIVD is a volunteer nonprofit with no product to defend. Merlon Security, credited with five of the ten researchers on the case file and named as DIVD's forensics partner, is a commercial consultancy that offers managed detection and response and penetration testing. Neither interest requires an agent. The pull on any victim's account is to explain a breach by something exceptional, and 'an AI agent' is exceptional. That is a pull to watch, not evidence of one.

Four labels, checked against the record

A comforting or alarming label is not a control and not a finding. Four labels are in circulation, and the record supports each one less than it sounds.

Four labels in the coverage and what the record supports. Sources: BleepingComputer (Bill Toulas, 30 September 2026), Security.NL, NCSC-NL, DIVD case files and CVE records.

Label	Where it appears	What the record supports
'AI-driven'	BleepingComputer headline: 'zero-days enabled AI-driven network breach'.	DIVD ties 'the agentic part' to the speed of the chain. The flaws are ordinary software flaws. No log, timing or model name is published.
'Zero-day'	DIVD, NCSC-NL and the coverage.	Supported by DIVD's dates for 21 September, and still true today for CVE-2026-102490. It says nothing about who held the flaws.
'Upgrade to version 7' and 'considered safe'	DIVD's advice. BleepingComputer adds that version 7 'is considered safe'.	DIVD says version 7 still contains the first flaw, 'not exploitable' on conditions it has not described, and the second flaw is in every version. DIVD does not say 'safe'.
'Actively exploited since 21 September'	NCSC-NL and Security.NL.	The only victim named in any source is DIVD, so the date is DIVD's own first-access date. No other compromised instance is stated.

Stated and not stated

What the records state, and what they do not, as of 11:55 BST on 1 October 2026. Sources: DIVD case files and LinkedIn post of 30 September, CVE.org records, NCSC-NL advisory NCSC-2026-0396, Zammad's release and advisory pages.

Topic	Stated	Not stated
Entry	Two chained Zammad flaws: session hijack, code as the zammad user, escalation to root.	How the intruder obtained them, what the 'passive' user action is, who or what fired the chain.
Dates	First access 21 Sep, reported to Zammad 24 Sep, owners notified from 26 Sep, CVE records public 30 Sep.	Times of day, when Zammad learnt of the flaws, when a fix will ship, whether its hosted service is affected.
Fix	DIVD: upgrade to version 7 or take it offline, Zammad 'working on a fix'. NCSC-NL: second flaw not fixed.	Any Zammad advisory, fixed version or release note naming either CVE.
Harm at DIVD	Attackers reached other services and could 'read and exfiltrate data'. Segmentation stopped them going deeper. 'Signs of compromise'.	Which data, how much, whose. DIVD plans an overview on 1 October.
Others exposed	DIVD scanned on 26 Sep and is notifying owners. NCSC-NL says exploitation since 21 Sep.	A count of exposed instances, a country breakdown, any second compromised victim.
Agent evidence	'In seconds, due to the agentic part of this hack'. Earlier: comments in scripts and tempo.	Logs, timings, counts, the model, the operator.

Zammad in the UK: named or counted?

Neither. DIVD's records give no count of exposed instances, no country breakdown and no list of notified owners. NCSC-NL's advisory is a Dutch publication, and we found no alert from the UK NCSC on 1 October. The only UK deployment visible is in Zammad's own marketing. Its customer page claims more than 2,000 customers, 55,000 users and 3.2 million downloads, and includes a case study of an Oxford college, labelled England, which says it has used Zammad since 2021. That page does not say whether the college hosts Zammad itself or buys the hosted service, or which version it runs, so it says nothing about exposure.

Hosting matters here. In its security release notes of 8 April, 25 June and 25 August, Zammad told hosted customers that no action was needed because its team had already patched. It has said nothing of that kind about these flaws. DIVD speaks of notifying 'owners of vulnerable instances', and both DIVD and NCSC-NL give advice for a server you run yourself, which suggests self-hosted installations are the audience. Neither says whether Zammad's hosted service was affected. That reading is inference from their wording.

A help desk usually holds personal data in its tickets: names, email addresses and whatever customers paste in. That is an inference about a typical deployment, not a statement about yours. If a compromise of yours involves personal data, the ICO says that where a risk to people is likely you must tell it 'as soon as possible, and where feasible within 72 hours'.

What to patch and what to read

This is defender guidance built from the records. The mechanism is withheld, and nothing here describes how to attack Zammad. Which versions. DIVD's advice, version 7 or offline, breaks the first step of the chain. It is not a fix for the second. On 6.3.0 to 6.5.4 the first flaw is exploitable according to DIVD, and Zammad has published no 6.5 security release since 6.5.4 on 8 April, so the route is an upgrade to 7. On 7.0.0 to 7.1.3 the flaw is present and 'not exploitable' on conditions DIVD has not described, which is not the same as fixed. Version 7.2.0, released on 23 September, is in neither of DIVD's lists, and the record does not say DIVD tested it. On every version the second flaw is open. For package installs, Zammad's notes for 7.1.1 say the old package repositories serve only versions before 7.1.x and are due to be shut down, so check your repository configuration.

What to read. NCSC-NL asks you to copy application and network logs before you update, because they may be needed later to show whether you were compromised in the zero-day phase. DIVD's case page mentions a script that checks Zammad logs for indicators of compromise, but we found no link to it and have not read it. Preserve first, at default locations that may differ on your system: the reverse proxy access and error logs (Zammad's sample nginx configuration writes to /var/log/nginx/zammad.access.log and zammad.error.log), the application log (production.log, usually under /var/log/zammad on package installs), the host's authentication and process-execution records for the zammad account, and anything showing the help desk host talking to other systems.

What to look for. One session used from a new address or client shortly after another. The zammad account starting shells or unexpected child processes. That account gaining root: changed sudo rules, new setuid files, new root-owned files, new scheduled jobs, new accounts or SSH keys. Connections from the help desk host to databases, directories, mail systems or internal APIs it does not normally call, and unusually large outbound transfers. Start at the beginning of your retention, not at 21 September: the first flaw has shipped since 2024, and the period in which anyone used it is unknown.

Containment is the other half. The one control DIVD credits is 'proper network segmentation', along with its response team. Ask what a root shell on your Zammad host could reach: database passwords, mail and OAuth tokens, directory bind accounts, API keys. If your search finds anything, rotate those secrets and read the logs of the systems they unlock.

What to do, in the order worth doing

What would change this today

Read DIVD's update and any Zammad response against six questions. Does DIVD publish timings or counts behind 'in seconds'? Does it say whether a person or the agent fired the chain? Does it say anything about how the intruder came to hold two Zammad zero-days? Which data was read and exfiltrated, and whose? Does Zammad publish an advisory with fixed versions, in particular for CVE-2026-102490, and say whether its hosted service was affected? Does anyone report a second compromised Zammad instance, or a count of exposed ones, in the UK or elsewhere? Each answer would move a row of the table above from 'not stated' to stated, and this briefing would need updating. On the KEV question, the catalogue was last cut on 30 September at 16:59 UTC, 38 minutes after CVE.org published the records and before NVD did, so its silence so far says little. Our briefing on two agencies and one CVE shows how far an exploitation label can differ between records.

The question that exposes the gap

Whatever ran the chain, a person or an agent, it ended at root on a help desk server. What could that server reach on your network, and which of your logs would tell you?

Key facts