Your patching policy has no entry for "there is no patch"

Your security policy says something like "critical vulnerabilities are remediated within 72 hours". Read it again, this time for the case where the patch does not exist. This is not a lab scenario: on 21 September someone broke into the Dutch organisation whose job is telling everyone else to patch, and eleven days later the second of the two flaws they chained still has no published fix. On the evening of 1 October the vendor said it finally had the details and was working on it. That sentence — "we are working on it" — is the one your policy cannot process.

What happened, with the victim's own dates

DIVD — the Dutch Institute for Vulnerability Disclosure — is a volunteer foundation that scans the internet for vulnerable systems and notifies their owners. On 29 September they published the casefile for the incident they had just suffered themselves. They gave the casefile a title that is not an accident: "When, not if…".

The timeline is theirs, not ours. 21 September: first access by the attacker. 22 September: they notice, block access to every system in the datacenter and stand up an incident response team with an outside firm, Merlon Security. 24 September: they report the vulnerability to the vendor, inform partners and affected parties and make their first public statement. 26 September: they open a second casefile to scan for vulnerable instances on the internet and notify their owners. 29 September: they publish the casefile. 30 September: they explain that the way in was two zero-days. 1 October: they publish which data got out.

Their first statement opens with two words: "We got hacked". And it closes with a working rule worth stealing: "Until proven otherwise, we handle this as a worst case scenario and assume breach". They notified the Dutch data protection authority, NCSC-NL, and talked to the police. On 1 October they told the awkward part: volunteer data got out, DIVD email addresses and possibly contact details. And they wrote the consequence themselves, which is the part that actually matters: it is now easier for someone to pose as a DIVD volunteer.

The headline is "an AI did it". That is not what decided the outcome

We have written twice about attacks run by AI agents, including the first breach notified in Spain with that attribution, so we will skip the astonishment. What is worth keeping from this case is that it contradicts the sales pitch. DIVD describe the attack as "loud and very messy, with the agent working automated and deciding each next step itself at speed on sloppy logic". And they add something better: "its overexplaining comments have made our reverse engineering a lot easier".

On 26 September they published two redacted screenshots from their logs: the attacker's scripts carried notes where the agent justified its own actions, explaining why what it was doing was fine and really not phishing. They point out, fairly, that a human attacker would not bother writing that. For us, what changed here is not stealth, it is tempo: from session hijack to root "in seconds", in their words. Noise favours the defender, yes — but only if somebody reads it. One calendar day passed between first access and detection, going by their own dates — they publish no times, so the real interval may be considerably shorter. That day appears in no patching policy, and it sets the ceiling for everything that comes after.

The chain, and why its second half is still open

The product they came in through is Zammad, an open-source support ticketing system, fairly common in IT departments and service companies. There are two chained flaws, and it is worth separating them because they behave differently:

• CVE-2026-102489 — session hijack leading to remote code execution as the zammad user. It affects versions 6.3.0 to 6.5.4. The casefile notes it is also present in 7.0.0 through 7.1.3, but there it is not exploitable due to environment conditions.
• CVE-2026-102490 — local privilege escalation: the machine's zammad user becomes root. The casefile says it is in "all versions of Zammad including the latest alpha", while the versions field narrows the range to v1.5.0 through v7.1.0-alpha.

On the evening of 1 October, in the official forum, the vendor wrote the operative sentence of this whole affair: "We have now received the details of CVE-2026-102490 from DIVD, and we are working on it. This issue cannot be exploited remotely on its own. An attacker would already need access to your server." In other words: the second flaw is link two. On its own it is not a door from the internet; it needs someone already on the machine. And link one does have a remedy today.

The field says "Available" and the paragraph says "are working on a fix"

There is a detail in the casefile nobody is talking about. The casefile for the two vulnerabilities has a header of structured fields, the kind that get pasted into a spreadsheet or swallowed through an API. They read: Recommendation: Upgrade to Zammad version 7. Patch status: Available. Workaround: N/A. A few lines below, in prose, the same document says: "We have reported the vulnerability to Zammad who are working on a fix."

The field fits the first flaw, the one that does have a version to move to. The paragraph is written in the singular, "the vulnerability", and does not say which of the two it means. That ambiguity is precisely the problem, and it is not ours to resolve. What we will say is that it is not the fault of whoever wrote the advisory, but of the shape of the advisory: there is no place in it for "half of this is fixed and half of it is not". And if your vulnerability management process consumes the field rather than the prose — which is exactly what an automated process does — this gets filed as closed. We have told this story before with another product: when "mitigated" turned out to mean turning it off and on, the state in the bulletin and the state of your machine were not the same thing either.

Two public documents that do not agree, and both are true

On 1 October the vendor published its own account. On the first flaw: they received it in August 2026, it is only exploitable on 6.5 and older because of the runtime those versions use, 7.0 and later are not affected, and they hardened the code anyway with the change shipping in 7.2.0. On the second: "Up to today, DIVD has not given us any technical details about this vulnerability. We cannot verify a claim we have not been shown." And they add a process complaint they do not hide: a CVE identifier was published for a vulnerability they had not been told about, and they conclude that "We do not consider this a responsible way to handle vulnerabilities."

We are not going to referee that disagreement. Both parties have published under their own names, with dates, in writing, which is more than most do. What interests us is what happens to the person running a Zammad: on 1 October they had to decide with two documents on the table that did not say the same thing — and for the two days before that, with only one. One told them to upgrade to version 7 or take it offline. The other told them version 7 is not affected by the remote flaw and that the scope of the other one cannot even be confirmed. Neither was lying, and the decision could not wait until they agreed. That is not a rare case: it is how advisories almost always arrive — one at a time, days apart, written by people holding different information.

What is left when the patch does not exist

A patch is one of the ways to render a vulnerability unusable. It is neither the only one nor, often, the fastest. The others do not depend on the vendor, they depend on you. You can break the chain at the other link, which is exactly the situation here: if the remote one stops working, the local one has no way to start. You can remove exposure: take the instance off the internet, put it behind the VPN, restrict it to known origins. You can cut the blast radius, which is what decided the scope of this incident — DIVD write it themselves: "Thanks to proper network segmentation and the actions of our IT and Incident Response Team after detection, we were able to stop the attackers from going deeper into our systems and network". And you can raise monitoring on that one system while the exception lasts, instead of on everything at once.

We say it constantly and here it shows with uncomfortable clarity: failure is inevitable, an outage is a design decision. DIVD had the failure on 21 September and could not avoid it, because there was no patch to apply. There was damage, and there is no point dressing it up: volunteer data got out and they are still investigating signs of compromise; they write it themselves, "Unfortunately some of the damage was already done". What did not happen is the full outage, someone walking the whole network. And the difference between the two was not made by a patch: it was made by architecture decisions taken months earlier and a team that was watching. That is the part you buy with time and money, not in a rush on advisory day. We work on it by rehearsing the continuity plan instead of filing it, which is the only way to find out whether the segmentation you drew actually exists.

The paragraph your policy is missing

Almost every security policy we read has patching deadlines by severity. Almost none has written down what happens when the patch does not exist, and that is the case you will actually face. So instead of another list of questions, here is the text. Copy it, swap the deadlines for yours and put it in the document:

"Where a vulnerability with known exploitation affects a system for which the vendor has published no fix, the systems owner shall open a written exception within 24 hours of becoming aware. The exception shall name: the affected system and its business owner; the containment measure applied while there is no fix, chosen from removing internet access, restricting it to known origins, isolating the system from the rest of the network, or shutting it down; the residual risk being accepted and who accepts it, by name and job title; the additional monitoring switched on for that system while it lasts; and the review date, which shall not exceed seven calendar days. The exception expires by itself on that date: if nobody renews it in writing, the most restrictive of the listed measures applies automatically."

The two clauses doing the work are the ones that look bureaucratic. Expiring by itself prevents what always happens: the exception is opened in good faith in September and is still open in March because nobody remembers to close it; if silence tightens rather than loosens, somebody reviews it. And the name and job title are not there to find someone to blame: they are there so the decision exists at all. A risk accepted by "the company" is accepted by nobody, and when the auditor — or the client who sent you their supplier questionnaire — asks why that system ran six of the seven days the clause allows with a known flaw, the difference between a governance incident and a well-handled footnote is that signed paragraph.

What we are not saying

This is not an argument against open source. Zammad is open, and our own infrastructure runs on Proxmox, Ceph, Zabbix and NetBox; to sell that line we would have to start by dismantling our own house. Paid software has exactly the same breakdown under another name: it is called end of support, or "fixed in the next major release, billed separately". The question "what do I do while there is no fix?" is neutral with respect to the licence.

Nor are we telling you to shut down your ticketing system. If you are on 7.2.0 and the instance is not published to the internet, your situation does not look like the headline — even though the local escalation still has no published fix — and acting as if it did costs money too. And if your company has fifteen people, you do not need a risk committee or a tool: you need a paragraph in a document and a person willing to sign it. Conflict of interest up front: we do not resell Zammad or any particular platform, so nobody pays us to recommend this; writing the policy, running the inventory and building the segmentation are work we do bill for.

One last thing, in fairness to the people having a bad fortnight. DIVD published their own disaster with dates, with what they knew and what they did not, and they wrote down why: "We don't wait until we have every answer, because that doesn't make digital society any safer." That is far more than most companies do when this happens to them. The fact that the casefile this article is built on exists at all is, precisely, to their credit.

Sources (verified on 2 October 2026): the timeline, the five public statements and every DIVD quote come from casefile DIVD-2026-00014, "When, not if…" (last modified 01-10-2026, 22:30 CEST). The version ranges, the Recommendation, Patch status: Available and Workaround: N/A fields and the phrase "who are working on a fix" come from casefile DIVD-2026-00015 (01-10-2026, 13:27 CEST). The vendor position and its quotes come from Zammad’s official statement in its community forum (01-10-2026). Reading the Patch status field against the prose paragraph, the tempo-versus-stealth argument and the policy paragraph with its two clauses are ours, not those sources’.