A helpdesk breach can reach far beyond the ticket queue

The Dutch Institute for Vulnerability Disclosure, or DIVD, says attackers entered its systems on September 21 through two vulnerabilities in Zammad, its helpdesk software. By October 1, it had confirmed that volunteer information had escaped, including DIVD email addresses; the full scope remained under investigation. This is a reported breach with a named victim, rather than a researcher demonstrating what might happen in a laboratory.

DIVD's incident statements and timeline

For a business using the same software, the immediate challenge is understanding which security boundary failed and which remedy addresses it. An upgrade can close an entry route without answering whether someone already entered. It can also address one vulnerability while leaving a separate problem unresolved. Treating the entire incident as a single update notification obscures both decisions.

What a support system knows

Zammad brings support conversations into a shared workspace. Staff can work with tickets and attachments, handle messages from several channels, and connect the system to other applications. It is available as a hosted service or a self-hosted installation. Those conveniences make it useful to small support teams as well as larger organizations: the next person answering a customer can see the history instead of starting again.

Zammad's product and integration overview

Consider a hypothetical equipment supplier with eight support staff. Its helpdesk holds installation photographs, customer contact details, warranty discussions and notes about recurring faults. An attached screenshot accidentally includes part of an internal dashboard. A long-running ticket explains which employee can authorize a replacement. None of those items is a master password, but together they describe people, routines and exceptions that an outsider would normally struggle to learn.

If that supplier's helpdesk were compromised, restoring ticket access would solve only the operational interruption. The business would also need to consider whether someone could convincingly impersonate support, refer to a real problem and persuade a customer to follow new instructions. This is a plausible consequence of exposed support records, not a claim about what happened at DIVD. It explains why the sensitivity of a helpdesk cannot be judged just by whether staff deliberately store passwords there.

The browser, the application and the server are different boundaries

A web session is how an application remembers that a browser has already signed in. The browser presents a session identifier as it moves between pages, rather than asking the user to enter a password each time. OWASP's session-management guidance explains why that identifier must be protected: control of an authenticated session can give someone the access associated with it. A session problem therefore concerns the application's recognition of a user, even when the user's password itself has not changed.

OWASP's explanation of web sessions and their protection

DIVD describes CVE-2026-102489 as a session-hijacking issue leading to remote code execution: the ability to make the server run unauthorized code. That code runs with the Zammad application's operating-system account. CVE-2026-102490 crosses another boundary, allowing that local account to gain root privileges, the broad administrative authority on the server. DIVD and Merlon Security investigated the vulnerabilities. The distinction matters because control of an application and control of its host are different levels of access.

DIVD and Merlon Security's Zammad vulnerability case

An application account exists partly to limit what a service can do. If a defect lets that account acquire administrative powers, the protection separating it from the rest of the machine has failed. Conversely, a local privilege-escalation flaw does not automatically provide an outsider with an initial way into the server. Both facts matter when estimating exposure. Internet accessibility, the installed software and any existing unauthorized access need to be considered together.

The upgrade advice needs two separate readings

The vulnerability case records a September 24 report to Zammad and limited public disclosure on September 26. Its October 1 update lists versions 6.3.0–6.5.4 for the exploitable remote-code-execution issue. It also distinguishes versions 7.0.0–7.1.3, where the underlying issue exists but environmental conditions prevent exploitation.

DIVD's affected-version details and disclosure timeline

Zammad's October 5 advisory says the first flaw is exploitable on 6.5 and older, unsupported releases. The runtime—the software environment executing the application—prevents exploitation in practice on 7.0 and later. Version 7.2.0 adds further code hardening. The vendor recommends immediately moving off the unsupported versions.

Zammad's affected-version and hardening assessment

The second flaw has a different status. Zammad says CVE-2026-102490 requires prior access to the underlying server and cannot be exploited remotely on its own. It links the problem to packager.io and says a solution is being developed. Its advice includes restricting server access to trusted administrators. The advisory does not establish that 7.2.0 fixes both vulnerabilities.

Zammad's October 5 assessment and remediation status

Recover the service without losing the explanation

Where compromise is suspected, contain access and involve whoever handles incident response before routine cleanup. Preserve relevant application, operating-system and network records, and arrange capture of volatile evidence where practical before restarting or rebuilding. Volatile evidence is information that can disappear when a system stops. NIST's forensic guidance explains why collection needs to account for that fragility. Containment and evidence collection should be coordinated so that preserving a record does not become a reason to leave an attacker connected.

NIST guidance on collecting and preserving incident evidence

Investigation should follow the actual installation. Which mail account feeds the tickets? Which integrations have credentials on the host? What other services could that machine contact? Answers narrow the review to real relationships. They also help sequence credential replacement: new credentials should be introduced from a trusted environment after the relevant access has been contained, rather than handed straight back to a machine still under suspicion.

For a self-hosted system with credible evidence of administrative compromise, plan recovery around a trusted replacement environment while retaining the old system for investigation. For a hosted service, obtain the provider's account of the affected environment and corrective work. In either case, a working login page demonstrates availability. It does not settle what information was accessed during the exposure window.

DIVD attributes the attack's behavior to an AI agent and says network segmentation and response actions limited further movement. Those are the victim's assessments. The AI attribution should not distract from the concrete administrative questions: which application was exposed, what authority it had, and what remained reachable after it failed.

DIVD's account of containment and its AI assessment

Source check: October 8, 2026. This article analyzes public reports from DIVD, Merlon Security and Zammad; Short Circuit did not discover these flaws. The incident investigation and second vulnerability's remediation were unresolved in the cited updates. The equipment supplier is a hypothetical example.