The Dutch Institute for Vulnerability Disclosure (DIVD) says the breach of its own network was possible because attackers exploited a chain of two zero-day vulnerabilities in Zammad, the open-source ticketing system. The Zammad zero-day DIVD breach is a pointed reminder that even organizations whose job is to find and report security flaws can be caught out by flaws nobody knew about yet.

The reporting available so far is brief, so this post sticks to what has been stated and explains why it matters.

How the Zammad zero-day chain breached DIVD

According to DIVD, the intrusion into its network was made possible by chaining two separate zero-day vulnerabilities in Zammad. A zero-day is a flaw that is unknown to the vendor or has no patch available when it is exploited, which leaves defenders with no ready fix.

Chaining matters. One vulnerability may give an attacker a foothold or limited access, while a second lets them go further, for example by raising privileges or reaching systems that should have been out of range. Combined, two moderate bugs can add up to a serious compromise.

Zammad is an open-source help desk and ticketing platform, commonly self-hosted by organizations to manage support requests. The source summary does not detail the technical nature of the two flaws, and we are not going to guess at them. Readers should watch for official advisories and patches from the Zammad project and from DIVD.

What the AI-driven attack changes for defenders

The headline describes the breach as AI-driven, and the suggested angle notes that AI tooling reportedly sped the attack. The details of exactly how AI was used are not in the material we have, so it would be a mistake to overstate it.

The general concern is still worth understanding. Automation can shorten the time between finding a weakness and exploiting it. If tooling helps an attacker discover, test, and string together vulnerabilities faster, the window defenders have to react gets smaller. That puts more weight on:

  • Fast patching once fixes are released
  • Limiting what an internet-facing application can reach inside the network
  • Monitoring that catches unusual behavior early, rather than relying on known signatures

None of this is a reason to panic. It is a reason to treat exposure management as an ongoing process rather than an occasional audit.

Why ticketing systems hold more sensitive data than you think

A ticketing system looks like a mundane tool, but it often collects a surprising amount of information. People describe their problems in free text, attach screenshots and logs, and include names, email addresses, account details, and sometimes credentials or internal system information. For a vulnerability disclosure organization, tickets can also relate to security issues that have not yet been fixed.

That makes these platforms attractive targets. They sit between the public and internal teams, they are frequently reachable from the internet, and they hold a long history of conversations that few people think to clean up.

The same pattern appears elsewhere. In the Adidas breach involving a third-party vendor, customer contact data was obtained through a compromised customer service provider. The lesson is similar: support infrastructure can become the weak point even when the core business systems are better protected. Data exposure can also happen in less direct ways, as in the case where OpenAI agents posted 53 ChatGPT images to public sites without authorization, a reminder that information shared with a service can travel beyond where users expect.

What This Means For You

If you have contacted DIVD or reported a vulnerability to them, watch for official communications from the organization about whether your information was affected. We do not have confirmation from the source of what data was accessed, so avoid assuming the worst, but stay alert to follow-up notices.

If you use Zammad or a similar self-hosted ticketing tool, this is a good moment to check your exposure. For everyone else, the takeaway is about habits: the details you hand to support desks may live in a system you know nothing about, run by a vendor you did not choose.

What organizations and users should check now

For organizations running Zammad:

  • Check the Zammad project and DIVD for security advisories and apply any patches promptly.
  • Review whether your instance needs to be exposed directly to the internet, and put it behind access controls where possible.
  • Segment the server from internal systems so a compromise does not become a network-wide problem.
  • Review logs for unusual activity and rotate credentials that may appear in old tickets.
  • Set retention rules so old tickets with sensitive content are not kept indefinitely.

For individuals:

  • Share the minimum needed with support teams, and avoid sending passwords, full ID documents, or payment details in tickets.
  • Use unique passwords for every service so a leaked ticket cannot unlock other accounts.
  • Be cautious with unexpected emails that reference a past support request, since attackers can use leaked ticket details to appear convincing. The Mayer Brown Luna Moth case shows how impersonation can work even without a genuine system compromise.

The takeaway

The Zammad zero-day DIVD breach shows that support and ticketing platforms deserve the same scrutiny as any other critical system. Patch quickly, limit exposure, and clear out data you no longer need. As a reader, take a few minutes to review what personal information you have shared with support desks and vendors, and consider how a breach at one of them could affect you. For a parallel example of customer-service systems becoming the weak point, read our coverage of the Adidas third-party vendor breach.