CISA has added CVE-2026-102489 and CVE-2026-102490, two vulnerabilities affecting the Zammad helpdesk platform, to its Known Exploited Vulnerabilities Catalog after confirmed exploitation in the wild. The addition is particularly significant because these are not merely unrelated bugs that happen to affect the same product. They can be chained together, allowing an attacker to move from remote exploitation of an Internet-facing Zammad instance to root-level control of the underlying server.

The first vulnerability, CVE-2026-102489, affects Zammad versions 6.3.0 through 6.5.4 and allows remote code execution as the zammad application user. DIVD also found the vulnerable code in versions 7.0.0 through 7.1.3, although it said exploitation in those builds was prevented by environmental conditions in the deployments it analyzed. DIVD scores the vulnerability at 8.7 High when considered on its own, but its practical significance increases sharply when it is combined with the accompanying local privilege-escalation flaw.

The second vulnerability, CVE-2026-102490, affects a much broader range of Zammad releases, from version 1.5.0 through 7.1.0-alpha, and allows the local zammad service user to escalate privileges to root. On its own, this requires a low-privileged local foothold and carries a CVSS score of 8.5 High. However, DIVD specifically evaluated the combined attack path and assigned the chain a 9.4 Critical score because the first vulnerability provides precisely the local execution context needed to exploit the second.

The resulting attack sequence is straightforward and dangerous: Internet-facing Zammad → CVE-2026-102489 → remote code execution as Zammad user → CVE-2026-102490 → root privileges → unrestricted operating-system access. The important point is that defenders should not evaluate these vulnerabilities independently. The first provides entry, while the second removes the remaining privilege boundary. Together they convert an application-level vulnerability into complete server compromise.

This chain has already been demonstrated in a real attack. DIVD says attackers used the two previously unknown vulnerabilities against its own environment on September 21, 2026. According to DIVD, the attack allowed session hijacking, remote code execution and privilege escalation from the Zammad user to root, after which the intruders accessed additional services and exfiltrated data. DIVD has also said an agentic AI system accelerated parts of the intrusion, enabling the attackers to move from initial exploitation to root access in seconds.

That history is what makes CISA’s KEV addition more important than an ordinary critical-vulnerability alert. KEV inclusion means there is credible evidence that attackers are already exploiting the vulnerabilities, not merely that exploitation is theoretically possible. Organizations running affected Zammad systems therefore do not have the luxury of treating remediation as routine maintenance.

The fact that Zammad is typically deployed as a helpdesk or ticketing system further increases the potential impact. Support platforms are often Internet-facing and contain substantial operational intelligence: internal hostnames, employee identities, customer correspondence, screenshots, uploaded files, troubleshooting logs, infrastructure details, passwords pasted into tickets, API tokens and other sensitive material. Root compromise of the server therefore potentially exposes much more than the application itself.

An attacker who gains root can inspect Zammad configuration files and retrieve credentials for databases, mail servers, LDAP or Active Directory integrations, OAuth services, backup infrastructure and other connected systems. Those credentials may then provide legitimate access paths into adjacent infrastructure even after the vulnerable Zammad server itself has been patched.

This is why organizations should treat confirmed exposure as an incident-response problem rather than only a patching problem. Updating Zammad closes the original vulnerabilities, but it does not remove persistence, revoke stolen credentials, delete unauthorized SSH keys, undo cron or systemd changes or establish that an attacker did not access connected systems before the update.

The correct remediation model is therefore: patch → hunt → rotate → validate, not simply patch and move on.

The vulnerabilities also demonstrate the value of exploit chaining. Neither flaw needs to provide everything an attacker wants by itself. CVE-2026-102489 delivers application-level execution, while CVE-2026-102490 provides privilege escalation. This modular attack model is common in real intrusions. Attackers rarely require one spectacular vulnerability when two ordinary ones can be combined to cross the same security boundaries.

That has an important implication for vulnerability management. Organizations sometimes assign patch priority almost exclusively according to individual CVSS scores. But the real-world attack path may be much more dangerous than either score suggests. A local privilege-escalation vulnerability can look less urgent because it requires existing access, yet it becomes critical when paired with an actively exploited remote-entry vulnerability on the same system.

CISA’s KEV catalog is useful precisely because it provides another prioritization signal: attackers are actually using this vulnerability. That practical evidence should often matter more than theoretical severity alone.

The Zammad flaws are also a useful example of why Internet-facing applications deserve accelerated vulnerability management. A helpdesk system must often accept connections from customers and employees outside the internal network. That makes it difficult to hide behind network segmentation or internal-only access. Once a remotely exploitable flaw appears, scanning and exploitation can begin quickly.

DIVD says it began scanning for vulnerable publicly accessible Zammad installations on September 26 and notifying identified owners. That proactive work is especially valuable because administrators may not always realize that an old helpdesk instance, test system or forgotten customer-support deployment remains reachable from the Internet.

Organizations should therefore perform an external inventory rather than relying purely on internal asset records. Forgotten DNS names, stale cloud instances and old NAT rules have an unfortunate tendency to remain very real from an attacker’s perspective even when they vanished from the spreadsheet years ago.

For defenders, the immediate priority is to identify every Zammad deployment and verify its exact version. DIVD recommends upgrading to Zammad version 7 or taking vulnerable instances offline, while Zammad’s current release line is 7.2. Administrators should follow the latest Zammad and DIVD guidance rather than assuming that simply being on any 7.x build is sufficient, because DIVD found vulnerable code in versions through 7.1.3 even where exploitation conditions differed.

Systems that were Internet-facing while vulnerable should be examined for evidence of post-exploitation activity. Because the chain can produce root access, investigation needs to extend beyond Zammad application logs. Security teams should inspect authentication records, shell histories where available, SSH configuration, newly created users, cron jobs, systemd services, sudo changes, recently modified binaries, suspicious files under temporary directories and unusual outbound network connections.

Any secrets accessible to the host should also be considered potentially compromised if exploitation is confirmed. This may include database passwords, SMTP credentials, LDAP bind accounts, OAuth secrets, API tokens and backup credentials. Rotating only the Zammad administrator password would provide very little reassurance after root-level compromise.

External logging is particularly important in this scenario. Once an attacker has root privileges, local logs can potentially be altered or deleted. Organizations should therefore rely on SIEM records, reverse proxy logs, firewall telemetry, DNS logs, identity-provider events and other off-host evidence when reconstructing activity. A compromised server should not be the sole historian of its own compromise. Computers, like humans, become rather unreliable witnesses when somebody has acquired root.

The known DIVD incident also demonstrates the value of segmentation. DIVD says the attackers were able to reach additional services and exfiltrate some data, but proper network segmentation and incident-response actions prevented them from moving deeper into the environment. This is an important reminder that even when an Internet-facing server is fully compromised, network architecture can still determine whether the incident remains contained or becomes an enterprise-wide breach.

Helpdesk servers should therefore not enjoy broad implicit trust merely because they are business applications. Their outbound and lateral access should be restricted to the systems they genuinely need: specific mail services, identity endpoints, databases and required APIs. Root on a Zammad server should not automatically mean unrestricted connectivity to domain controllers, management networks or unrelated production systems.

The incident also has a broader lesson around machine-speed exploitation. DIVD’s earlier investigation indicated that an AI agent played a significant role after initial access, rapidly evaluating results and selecting subsequent actions. Whether every future attacker uses AI is almost beside the point. Once the vulnerability chain is public and confirmed as exploitable, automation can make scanning, exploitation and post-compromise activity much faster regardless of whether the automation happens to contain a fashionable language model.

Defensive response therefore needs to account for shrinking timelines. If an attacker can move from remote entry to root in seconds, security programs cannot depend exclusively on a human analyst eventually noticing an alert and manually containing the system. High-confidence exploit or post-exploitation detections increasingly need automated controls capable of isolating hosts, blocking identities or restricting network access before the attacker has finished the next stage.

The two KEV additions also illustrate a useful vulnerability-management principle: context beats score. CVE-2026-102490 by itself is local. Pair it with CVE-2026-102489 and the practical attack surface becomes remote. CVE-2026-102489 by itself compromises the application account. Pair it with CVE-2026-102490 and the impact becomes root. The security risk exists in the chain, not merely in the rows of a vulnerability scanner.

Organizations should therefore build prioritization around realistic attack paths: What can the attacker reach first? What privilege does that provide? Which local vulnerabilities become usable next? What credentials become accessible afterward? Which systems can the compromised host reach? That model provides a much closer approximation of real risk than sorting thousands of CVEs by CVSS and hoping the highest number is always the most dangerous.

CISA’s October 2 KEV update therefore reinforces what the DIVD incident had already demonstrated operationally. These vulnerabilities are not waiting for somebody to determine whether they can be weaponized. They already were.

The attack chain is known:

remote exploitation → Zammad user → local privilege escalation → root → service access → potential data theft and lateral movement

For organizations running Zammad, that should shift the response from:

“When is our next patch window?”

to:

“Was this system exposed while attackers already knew how to compromise it?”

That is the question the KEV listing is really asking defenders to answer.

CISA has added two new vulnerabilities to its Known Exploited Vulnerabilities (KEV) Catalog , based on evidence of active exploitation. CVE-2026-102489 Zammad GmbH Zammad Session Fixation Vulnerability CVE-2026-102490 Zammad GmbH Zammad Improper Privilege Management Vulnerability These types of vulnerabilities are frequent attack vectors for malicious cyber actors and pose significant risks to the federal enterprise. Binding Operational Directive (BOD) 26-04: Prioritizing Security Updates Based on Risk establishes vulnerability management requirements for Federal Civilian Executive Branch (FCEB) agencies. BOD 26-04 reinforces the importance of the KEV Catalog and requires federal agencies to prioritize rapid remediation of high-risk vulnerabilities, specifically those identified by Common Vulnerabilities and Exposures (CVEs) listed in CISA’s KEV Catalog on publicly exposed assets that grant total control of the asset post-exploitation, while deferring action for lower-risk vulnerabilities. BOD 26-04 further establishes basic expectations for when agencies must check whether threat actors compromised the system before the patch was applied. While BOD 26-04 applies only to FCEB agencies, CISA encourages all organizations to adopt risk-based vulnerability management and prioritize remediation of KEV Catalog vulnerabilities . CISA will continue to add vulnerabilities to the catalog that meet the specified criteria . Aware of an exploited vulnerability not currently listed in the

Source: CISA Adds Two Known Exploited Vulnerabilities to Catalog via CISA Advisories — published 02 Oct 2026.