DIVD Breached via Zammad Zero-Day Chain

The Dutch Institute for Vulnerability Disclosure (DIVD) disclosed this week that its internal network was breached through a chain of two unpatched zero-day vulnerabilities in Zammad, the open-source ticketing platform the organization used to manage vulnerability disclosures. BleepingComputer reported the incident on September 30.

DIVD is a nonprofit made up of volunteer security researchers that finds vulnerabilities in products, notifies vendors under responsible disclosure, and tracks remediation. Its databases and case management systems hold active vulnerability data: information about unpatched flaws in third-party products, affected vendor contacts, and the status of ongoing disclosures. The breach of an organization holding that data is a different order of problem than a typical corporate intrusion.

According to DIVD’s own disclosure, the attackers exploited two zero-day vulnerabilities in Zammad in sequence. Zammad is a widely deployed open-source help desk and ticketing platform. The specific flaws have not been assigned CVE identifiers as of the time this article was written, and technical details of the vulnerabilities remain limited. DIVD’s disclosure describes the attack as “AI-driven,” a characterization the organization applied to the breach without elaborating on which attacker tools or techniques carried that label.

What was at risk

The question of scope matters here more than usual. An organization that manages active vulnerability disclosures is handling data that has not yet been made public. If attackers accessed case files before remediation was complete, they would have had visibility into vulnerabilities that affected vendors did not yet know were known to someone else. That creates an asymmetry: attackers who can read a DIVD-managed disclosure timeline gain a window to prepare or act before a patch exists.

DIVD has not stated whether active case data was accessed, exfiltrated, or used in any subsequent operation. Until that question is answered, the full impact of the breach cannot be assessed. The organization’s disclosure confirmed the breach occurred; the consequences for any third-party software vendors or their customers remain open.

Zammad exposure and the patch question

Zammad is installed on-premises in many security operations centers, managed service providers, and IT support teams, often in configurations that handle sensitive internal communications. If the two exploited vulnerabilities are reproducible against other Zammad deployments, any organization running an unpatched version of the software is potentially in scope until patches are released and applied.

No Zammad security advisory for these specific vulnerabilities was publicly available at the time of writing. Organizations running Zammad should monitor the project’s security advisories and apply any released patches promptly. Limiting public access to the Zammad interface and requiring authentication from a restricted network range reduces exposure while waiting for vendor guidance.

The broader pattern

It would be easy to read this story as ironic, and the irony is real. An organization whose purpose is to find and disclose vulnerabilities in other people’s software got breached through an unpatched zero-day in its own ticketing system. Security practitioners talk about the impossibility of perfect defense; here is another reminder of what that looks like in practice. DIVD’s own disclosure work depends on access to systems its volunteers chose based on availability and function, not necessarily on a rigorous security evaluation of each component in the stack.

That pattern runs through most real-world breaches. The attack surface is rarely the part of the stack anyone spent the most time worrying about. It tends to be adjacent infrastructure: the tool the team uses to manage the work, the authentication layer nobody reviewed, the vendor whose component nobody included in the threat model. Zero-days in that category of software are particularly dangerous because patching is contingent on the vendor, not the operator.

DIVD’s willingness to publish its own breach publicly and in detail is exactly the behavior the responsible disclosure community exists to encourage. The disclosure does not make the breach less serious; it makes the information available to the organizations that need it.

For related threat-actor coverage, see Arizona Supreme Court Confirms Resident Data Stolen and Kiteworks Patches Critical Flaw, Lifts Shutdown Order. For the vulnerability disclosure ecosystem, see the threat intelligence topic hub.