On 21 September 2026, attackers chained two previously unknown vulnerabilities in Zammad, a self-hosted ticketing system, and went from the application to root on a server belonging to the Dutch Institute for Vulnerability Disclosure. DIVD published the details on 30 September. It says the sequence took seconds.
DIVD runs coordinated disclosure for the Netherlands, and it was breached through its own help desk. It is also one of the few organizations to have contained an intrusion of this shape.
The part to hold on to is the interval. When a chain completes in seconds, every remaining control works by noticing something and then acting, and each is measuring an event that has already finished.
What actually happened
DIVD's case file describes the two CVEs in sequence. CVE-2026-102489 produces, in DIVD's wording, "remote code execution as a Zammad user which can be used for session leakages", affecting versions 6.3.0 to 6.5.4 and present but not exploitable in 7.0.0 to 7.1.3. CVE-2026-102490 then allows "the local zammad user to escalate privileges to root", with every version affected.
| Date | Event |
|---|---|
| 21 September | DIVD's Zammad instance is exploited |
| 22 to 23 September | DIVD reproduces and analyzes both flaws |
| 24 September | Zammad is notified. DIVD states publicly that it was breached |
| 26 September | DIVD begins internet scanning and notifying owners of vulnerable instances |
| 30 September | Both vulnerabilities disclosed |
Sources disagree on a detail that matters. DIVD's own case file states that CVE-2026-102489 requires Zammad user access, while SecurityWeek and Help Net Security describe the remote code execution as needing no authentication. DIVD has not said how the attackers obtained whatever foothold they started from. Either reading leaves the same precondition: they reached the application over the network first.
From root, DIVD reports that the attackers pivoted to other services and exfiltrated data, and that network segmentation and its incident response team kept them from going deeper. DIVD assesses the operation as agentic, on behavioral rather than technical evidence: it describes the attack as loud and very messy, and says the agent left behind clear explanations of its own decisions.
The attackers did not need the response team to be slow. They only needed the chain to finish inside an interval nobody responds in, and seconds is that interval.
The gap: everything still standing needed time
None of DIVD's controls failed at what they were built to do. They were asked for something none of them offers, which is a decision taken before the first connection.
- Patching had nothing to apply. Both flaws were unknown on 21 September. DIVD's advice to every other Zammad operator, published after the fact, is to upgrade to version 7 or take the instance offline.
- Identity controls were not the barrier. If DIVD's reading is right and a Zammad user was required, the attacker had satisfied that test before the chain ran. If the other reading is right, no credential was ever presented.
- Detection and response worked, and they are why this is a contained incident. They also engaged on an intrusion already running as root, because that is where in the sequence they sit.
- Segmentation worked too, and did the most here. It governs how far an intrusion travels, not whether it starts.
Response time is the one variable an attacker chooses, and an operator running an automated chain can choose a number no defender beats.
What would have had to be true
For the chain never to start, the Zammad web interface would have had to not answer the network the attackers were on.
That is a capability of whatever firewall or reverse proxy sits in front of a self-hosted application, and not an advanced one. The difficulty is that the answer changes constantly. A help desk is worked by staff and volunteers from offices, homes and hotel networks, and a hand-maintained list of their addresses is stale within days. An address left in too long is silent, while a missing one is a support ticket in minutes, so the range gets widened until it has stopped being a control.
Where Veribound would have fitted
Veribound is a Pre-session Edge Access Control platform, an intelligence layer rather than an enforcement point. Agents on each device continuously attest whether it is still the one the organization trusted, and a trust-scoring engine turns those attestations into a per-device decision. What reaches the customer's existing controls is a trusted origin: the network that device is connecting from, in practice its public address, while the device behind it is still trusted. Those origins are written into the address groups the organization's own policy already references, and its own equipment keeps enforcing its own rules, unchanged.
Applied to the staff-facing side of a self-hosted help desk:
- The edge answers trusted origins, so a scan of that address space returns nothing and the application never enters a target list.
- Both zero-days still exist and the upgrade is still required. What changes is who was in a position to test them on 21 September.
- The list stays current on its own, which is the part that fails when people maintain it by hand.
- Segmentation, detection and response all stay exactly where they are, and now they meet a smaller population.
The limits need stating plainly, and one is specific to this kind of system. Many help desks publish a portal so anyone can file a ticket, and DIVD's own work depends on strangers being able to report things. No origin decision applies to a surface whose job is to answer the public. The claim here covers the agent and administrative paths, where Zammad sessions exist and the population is a bounded set of people on attested devices. An organization serving both from one hostname has a separation problem before it has an origin problem.
Nor would any of this have patched either flaw, helped against an attacker working from a device and network already trusted, interrupted the outbound exfiltration, which is an egress question, or undone root access. Veribound does not enforce anything. It supplies the trusted origins that the equipment an organization already runs acts on.
The narrow claim is the one that holds. On 21 September the difference between an affected Zammad instance and an unaffected one was not how fast anybody could respond, because nobody responds in seconds. It was whether the application answered a stranger.
Source: DIVD says Zammad zero-days enabled AI-driven network breach, BleepingComputer, 30 September 2026.