CISA has added two Zammad vulnerabilities to its Known Exploited Vulnerabilities catalog, turning a disputed disclosure into an immediate operational question for organizations running the helpdesk software. The October 2 entries identify CVE-2026-102489 and CVE-2026-102490, and flag both for forensic triage. That is the development to act on. Whether an AI agent drove the attack is a separate question from whether an exposed support system needs attention. Administrators should not wait for the most dramatic part of the story to be settled before examining the software they actually operate.
The Dutch Institute for Vulnerability Disclosure, or DIVD, says the flaws were used to breach its infrastructure. Its vulnerability case describes an initial route into the Zammad application account followed by a separate route to root privileges. DIVD recommends moving to version 7 or taking vulnerable installations offline. It also offers a log-checking script for indicators of compromise. Those are specific, bounded statements. They do not establish that every deployment has been breached, that every version is equally exploitable, or that the second vulnerability has a confirmed fix in the current release.
The first vulnerability record describes remote code execution under the Zammad user's identity. That distinction matters: running code as an application account is already a serious failure, even before an attacker obtains broader machine control. DIVD says the relevant code is also present in versions 7.0.0 through 7.1.3, but environmental conditions prevent practical exploitation there. Vulnerable code and an exploitable deployment are not interchangeable descriptions. A version inventory is a starting point, not a substitute for understanding the runtime conditions identified by the people analyzing the flaw.
The second record describes a local privilege-escalation path from the Zammad user to root. By itself, a local flaw has a different starting condition from an unauthenticated remote entry point. In a chain, the first weakness can supply the access that the second requires. That is why evaluating each identifier as an isolated ticket can miss the operational problem. The relevant question is whether an attacker can traverse the combined path. It is not helpful to dismiss a local issue merely because the initial contact with the system happened remotely.
Zammad's October 1 statement agrees that the first issue is not practically exploitable on version 7 and later. The vendor says it received that report in August, hardened the affected code in 7.2.0, and recommends updating to that release. It describes 6.5 and older as unsupported. On the second issue, however, Zammad says DIVD had not supplied technical details and that it could not confirm the vulnerability, affected versions or scope. DIVD's broad privilege-escalation claim and the vendor's inability to verify it remain separate positions in the material reviewed.
That disagreement cannot responsibly be compressed into either a clean bill of health or a claim that every current installation is remotely exploitable. Nor should the case page's general patch-availability field be read as a vulnerability-by-vulnerability guarantee. The defensible distinction is narrower: the parties describe a break in the initial exploit path on newer versions, while the privilege-escalation question remains unresolved between them. An operational decision can acknowledge both facts. Record which exposure an upgrade addresses and which question still needs an explicit advisory, rather than closing the entire incident under one green status.
The disclosure timeline also needs attribution. DIVD lists a September 21 breach, a September 24 report to Zammad, and scanning and limited disclosure on September 26. Zammad disputes the handling of the second report and says the first issue had already been reported earlier. These accounts do not establish who possessed which technical details at every stage. The important practical demand is for enough specificity to identify affected installations and effective mitigations. Assigning blame before that record is complete would add certainty without adding protection.
Independent reporting provides useful context, but it does not independently prove the attacker's autonomy. BleepingComputer's September 30 report relays DIVD's account of an AI agent that left explanations of its decisions in attack scripts. The report also describes Zammad as a helpdesk used for customer inquiries, internal tickets and IT support. This is a consequential place for an intrusion because it organizes operational correspondence, not merely public marketing content. The independent article should be read as reporting on the victim's investigation, not as a separate reproduction of the exploit chain or the claimed AI behavior.
DIVD's own incident statements say script comments and the attack's behavior support its assessment of an agentic attack. It also says it had found no link to a known public threat actor and had not established deliberate targeting of its most sensitive assets. Those limits matter. Comments that look like an agent explaining itself are evidence to investigate, not a complete account of the model, operator or degree of human direction. Nothing in this report independently validates those details, and the unresolved attribution does not diminish the need to address the underlying access paths.
The breach account contains a less spectacular but more actionable observation: DIVD credits network segmentation and its incident-response team with preventing deeper movement. That is a report from the affected organization, not a controlled comparison of defenses. Still, it provides a concrete reason to examine what a support server can reach after its application account is compromised. Containment should be evaluated against the services and credentials actually connected to that server. A successful restriction on onward access can matter even when the initial application has already failed.
DIVD's separate data-investigation page makes the impact more precise. It confirms exfiltration of volunteer email addresses, with possible contact details and the exact affected population still under investigation. It warns that organizations corresponding with its CSIRT should assume attackers may have obtained those exchanges. The ticketing system held incoming messages and replies, but not the initial notifications. That distinction changes whose information needs attention. It is not equivalent to saying that every organization ever notified by DIVD had its complete record stolen.
The same page separates investigation status, preliminary analysis and final assessment. Lists of vulnerable systems and vulnerability information appear among the categories being examined; appearing in that inventory is not confirmation of theft. Readers should preserve that distinction when forwarding the warning internally. A sensible response is to identify what your organization actually sent, who owns it and what exposure would mean if the correspondence was obtained. Treating an investigation list as a confirmed leak can produce unnecessary alarm while obscuring the narrower information that does warrant follow-up.
Support policy is another part of the exposure calculation. Zammad's published security policy provides fixes for the current stable release only and requires older installations to be updated. It also calls for separate reports for independent vulnerabilities and says acknowledged issues receive security advisories. For a self-hosting team, that policy belongs in the operating plan before an emergency. Keeping an older deployment functioning does not mean the maintainer has promised to keep repairing it. Ownership includes the ability to move with the supported release, not just the ability to install the software once.
The vendor's security-advisory index is therefore a better place to seek a precise resolution than a generalized assurance that an upgrade makes everything safe. The index reviewed for this report did not supply an advisory resolving the disputed privilege-escalation claim. That observation is limited to the material available at review time; absence from the page is not proof that a vulnerability does not exist. Administrators need a statement that connects the specific identifier, affected conditions and corrective action. A product version number without that connection answers less than it appears to.
Actually upgrading has constraints that a headline cannot perform away. Zammad's update documentation says not to skip major versions, to check dependencies and release notes, and, for package installations, to stop the application and take a backup. It warns that maintenance-script output can reveal incomplete updates and that ignoring it can lead to problems. Docker Compose installations have their own release-note requirements. The right change plan depends on the deployment in front of the operator. Copying a command intended for a different installation type is not a substitute for that plan.
The backup documentation adds an easily missed limitation. The supplied package scripts do not cover container or source installations. They create full dumps, not incremental or partial backups, omit system settings such as environment variables, and cannot restore to an older Zammad version. The documentation explicitly recommends regular testing. For incident planning, that means a backup file should not be casually described as a complete rollback strategy. Know which configuration must be recovered separately and whether the restore destination meets the documented constraints before treating recovery as a solved problem.
Maintenance mode is similarly narrower than its reassuring name. Zammad documents it as restricting access to administrative roles and logging out agents and customers. That can help coordinate ordinary maintenance, but the page does not establish it as network isolation or a mitigation for these vulnerabilities. If a response plan calls for taking a vulnerable instance offline, a login restriction should not silently stand in for that action. State the intended containment result explicitly, then verify it through the controls responsible for that boundary.
CISA's catalog also separates remediation from investigation by marking forensic triage as required for these entries. Both list ransomware-campaign use as unknown, which should not be rewritten as either confirmed ransomware involvement or proof of its absence. For the operator, there are distinct questions to assign: what remains exposed, what software change is appropriate, and what evidence exists of earlier access. Completing the update addresses one part of that work. It does not, by itself, establish what happened before the update or which correspondence may have left the system.
The useful lesson is not that open-source helpdesks are inherently unsafe, or that every future intrusion will be an autonomous AI operation. This case supports neither conclusion. It does show why a support application deserves an explicit owner for upgrades, recovery, access boundaries and incident communication. Those responsibilities are connected but not interchangeable. A team can make progress on the agreed exposure while demanding better evidence on disputed scope. The next meaningful proof point is a precise technical resolution and a clearer account of the data impact, not a more dramatic label for the attacker.
LaunchPad positionAddress the agreed exposure while keeping the privilege-escalation question and data investigation open.
This report draws on the linked primary sources and reputable reporting. Company statements are treated as claims until independently demonstrated.