Zammad's chained zero-day is on CISA's KEV catalog: what I checked on my swarm when the LPE hits an app I do not run

Two Zammad zero-days chained together broke into the Dutch Institute for Vulnerability Disclosure on September 21, 2026 ¹. The first, CVE-2026-102489, is an unauthenticated session hijack that lands as remote code execution under the zammad application user ². The second, CVE-2026-102490, takes that user and hands it root ¹. Chained, they take an attacker from the public web port to a root shell, and CISA lists the privilege escalation in its Known Exploited Vulnerabilities Catalog ³. That puts a class of self-hosted app on my radar, so I went through my homelab, container by container. I do not run Zammad. The check was to confirm that and to find what I do run that the same reasoning reaches.

The chain and where it bites

CVE-2026-102489 gives an attacker who has no account a foothold. It is a session-hijack weakness that lands as code execution running as the zammad user, and its published score is CVSS 9.4 ². The second flaw does the rest. CVE-2026-102490 is an improper privilege management bug that lets the local zammad user escalate to root, also CVSS 9.4 ², and the community report on it says no user interaction is required ⁴.

The order is the whole problem. The RCE alone leaves you with a low-privilege foothold inside the app. The LPE turns that foothold into the machine. Divided, each is a single step. Chained, an attacker who can reach the web port moves from zero to root in one pass, and DIVD said the chain ran in seconds, driven by the agentic part of the attack ².

What DIVD hit

DIVD is the Dutch institute that assigns CVEs for a large share of European software, and the attackers went after its own ticketing instance. The intrusion landed on September 21, 2026 ¹. DIVD blocked access to its infrastructure and opened an incident response the same day ², reported both flaws to Zammad on September 24, and began scanning for other exposed vulnerable instances on September 26 ¹.

DIVD flagged the method more than the target. An agentic AI system drove the exploit steps end to end, and the institute described the intrusion on that basis ². The attackers pivoted from the Zammad box to other services and exfiltrated data, but segmentation stopped them before they went deeper ².

The version catch

The fix is to upgrade, and the version list has a catch worth sitting on. DIVD places the RCE in Zammad 6.3.0 through 6.5.4, present in 7.0.0 through 7.1.3 but not exploitable there because of environment conditions ¹. The LPE reaches much wider, covering 1.5.0 through 7.1.0-alpha, which spans nearly every release ¹.

Moving to the 7 line clears the remote entry point, the RCE, but it does not clear the privilege escalation. A 7.x instance still sits inside the LPE range ¹. DIVD advises upgrading to version 7 or taking the instance offline ¹, and the LPE range is what makes the offline option the one that closes both flaws. Whether Zammad ships a patch that clears the LPE, and when, is the thing I will watch next ¹.

What I checked on my swarm

I do not run Zammad. I walked my homelab container list to confirm that and to look at what I do run in the same class. My home hosts carry a logging stack, an OpenViking instance, and a DNS rebinding guard, and none of them is Zammad or another open-source ticketing platform.

The check runs on two properties that this chain needs and that anything I do run can have. The first is a web service reachable from the internet. The second is an application process that runs under a low-privilege user with a known path to root on the host. A self-hosted ticketing app has both by default, which is why the chain worked.

I asked the same two questions of the services I do run. Is the port reachable from the internet without a login? Does the app run as its own user, or does it have a sudo or SUID path to root? The ones that answer yes to both are the ones I would treat like this advisory, even though none carries this specific CVE.

The class check

An actively exploited LPE in a self-hosted app I do not run is still a useful advisory, because it names a class and a failure mode. The failure mode is that the app’s own user is a stepping stone to root, so a compromise of the app is a compromise of the host. The class is any web service I expose that runs a process with a root path.

Three habits close that class. Keep the web port off the public internet unless it has to be, and put the service behind authentication instead of trusting the app to be unguessable. Run the app as its own low-privilege user and remove its path to root, because the LPE is what turns an app bug into a host bug. Segment the network, because DIVD’s attackers reached other services from the Zammad box and stopped only where segmentation stopped them ².

I do not run Zammad, and I will not stand one up to fix a bug I do not have. The advisory belongs in my queue because it names a property I own on other services and the exact step that turns an app flaw into root on the host.