Zammad Zero-Days: Your Help Desk Is Full of Pasted Passwords

Ask any support team where customers send passwords and the honest answer is: into the ticket. That is why a vulnerability in a help-desk platform is worth more than its install base suggests. Two flaws in Zammad, an open-source ticketing system, were added to CISA's Known Exploited Vulnerabilities catalog on 2 October after the Dutch Institute for Vulnerability Disclosure (DIVD) found that attackers had used them against its own instance.

Patching is the obvious step. The less obvious one is deciding what your ticket history already contains, because a system that has run for years holds more secrets than anyone wrote down.

What is confirmed

DIVD's case write-up (DIVD-2026-00014) says two zero-day vulnerabilities in Zammad were exploited against it. It dates initial access to 21 September and detection to 22 September, when DIVD blocked access to its datacenter. The attackers, it says, hijacked sessions, ran code as the Zammad user, escalated to root, reached other services and exfiltrated data. DIVD names the data it has confirmed as taken: volunteer contact information, including email addresses and possibly further contact details. It adds that network segmentation stopped the attackers from going deeper.

The two CVEs are CVE-2026-102489, a session fixation flaw that leads to remote code execution as the Zammad user, and CVE-2026-102490, a privilege-management flaw that lets that user become root. Security Affairs reports CVSS 9.4 for both and a CISA remediation deadline of 5 October for US federal agencies. DIVD and the reporting we reviewed recommend Zammad 7 as the safe version, or taking an instance offline if you cannot upgrade immediately.

What is not known

Exact affected versions. Outlets give different ranges, and the DIVD page we read does not list them. Take the ranges from Zammad's own advisory, not from this article.
Attribution and other victims. DIVD does not say who was behind it, whether it was targeted at DIVD, or whether anyone else was breached.
The AI-agent claim. DIVD says the attack was run by an autonomous agent, citing notes in the attacker's scripts in which the agent explains its own actions, and calls the intrusion loud and messy. That is DIVD's assessment of its own incident. We have not seen independent verification, and it does not change what you have to do.
Scope at other sites. Nothing published says what, if anything, was taken from other Zammad deployments.

Why a ticketing system is a secrets store

Nobody sets out to make the help desk a vault. It happens through convenience: a customer pastes a temporary password so an agent can reproduce a problem, an engineer attaches a config file, someone forwards an email thread with a token in it. Tickets are searchable, retained for years and readable by a wide group of agents, which is the opposite of how a credential should be stored.

A root compromise of the host reaches the database where all of that lives. It also reaches whatever the application itself needs to run, which for a help desk typically includes credentials for the mailboxes it reads, the directory or single sign-on it authenticates against, and any chat or API integrations. Whether any of that was taken in a particular incident is a separate question, but you cannot answer it without knowing what was there.

A response order for self-hosted Zammad

Decide whether you can prove it was untouched. Internet-facing instances running a vulnerable version should be treated as potentially compromised. Look at access and application logs for unusual sessions and privilege changes, and preserve them first.
Upgrade to Zammad 7, or take the instance offline. That is the guidance in the reporting. If the host was compromised, a rebuild from a known-good state is safer than an in-place upgrade.
Rotate what the application and host could read. That means the database password, the application's secret keys, the passwords or tokens for connected mailboxes, directory bind accounts and API tokens, and any SSH or backup credentials on the host. Revoke active sessions at the same time.
Search your ticket history for credentials. Start with the obvious patterns: the words password, token, key, secret and credential, long random-looking strings and attached config files. Treat any live credential you find as exposed, rotate it and then remove it from the ticket.
Tell affected customers when their credentials were in a ticket. Whether to notify is a legal and contractual question, so involve whoever owns that in your organisation.
Check the segmentation that mattered at DIVD. Segmentation is what limited the damage there. Confirm the help-desk host cannot reach production systems it has no need for.

Stop collecting the problem

Cleaning old tickets fixes yesterday. The habit that fills them is what needs to change. Give agents a canned reply that says passwords and keys do not belong in a ticket, and provide the alternative at the same moment, because “please do not do that” without a replacement just moves the paste somewhere else. Configure retention so closed tickets are not kept indefinitely, and limit who can search attachments.

When an agent genuinely needs a one-time value from a customer, such as a temporary password or a recovery code, ask for it through a link that expires and leave only the fact that it was received in the ticket. When an agent has to send a value out, the same applies in reverse.

Where Secretus fits, and where it does not

Secretus is built for that narrow exchange. The sender writes a short text secret in the browser, where it is encrypted, and shares a link. In the default mode the server stores only ciphertext, and the link stops working after the expiry you set or after the first successful open. The ticket then holds a record that the exchange happened, not the value itself.

It is not a help-desk platform, a secrets manager or a log-scrubbing tool. It does not remove credentials already sitting in your tickets, patch Zammad, rotate a mailbox password or tell you whether your instance was breached. Do those with your own tooling, and use a one-time link so that the next password is not added to the pile.