A helpdesk platform is not usually treated as critical infrastructure. It holds the conversations a company has with its customers, the email addresses of everyone who ever opened a ticket, and, in most deployments, a trusted connection to the directory that authenticates employees. In late September 2026, two zero-day flaws in Zammad were used together to take one such platform from an unauthenticated request to root on the host, and the victim was an organisation whose entire job is handling vulnerability reports.
The two flaws
CVE-2026-102489 is a session hijack vulnerability in Zammad 6.3.0 through 6.5.4 that leads to remote code execution as the zammad service user. The same defect exists in 7.0.0 through 7.1.2, but NVD records that framework changes make it not exploitable there. Score: 9.4 under CVSS 4.0.
CVE-2026-102490 is the second half, and it is the half worth studying. NVD describes it as an issue in Zammad packages built with packager.io, both DEB and RPM. Service processes started as root and executed files owned and writable by the unprivileged zammad account before dropping their identity to that account. A local attacker who already had file write access as the service account could therefore control what root executed. Score: 9.4.
Read those two descriptions together and the shape of the chain is obvious. The first bug gets you code execution as a service account. The second bug turns "code execution as a service account" into "code execution as root" without any additional memory corruption, kernel exploit, or misconfiguration. The privilege boundary between the application's user and the operating system was, for these packages, effectively a three-line privilege drop with an ownership mistake in front of it.
What the incident report adds
The Dutch Institute for Vulnerability Disclosure, known as DIVD, disclosed that it was compromised. Public reporting on the case, which DIVD itself documented as a case file, describes the entry as the two Zammad flaws chained together, with the compromise discovered the day after it began. The reporting further states that the post-exploitation activity was carried out by an autonomous agent that chose its own steps, and that volunteer email addresses and parts of a ticketing workflow were exposed.
Two claims in that narrative deserve separate treatment.
The first is technical and well supported by the vendor classification: two vulnerabilities, both rated critical, one enabling remote code execution as the service account and one escalating to root. That part is a fact about the software.
The second is about the attacker's automation. An autonomous agent that plans its own actions changes the tempo of an intrusion, because it does not need a human to read a tool's output before choosing the next step. It does not change what defenders should do about a writable-by-service-account privileged process. The mechanism is conventional.
Why services that run as root before dropping privileges keep producing this bug
The pattern is old and appears in software written in every language. A daemon starts as root so it can bind a low port, read a protected configuration file, or touch a socket it will not need again. Then it calls a function to become the unprivileged user. Everything between process start and that call executes with full privileges, and any file path in that window is attacker-controlled if the unprivileged user can write to it.
For Zammad the window was wide enough to matter for packaged installations. Web applications commonly run from a directory their own service user can write to, because deployments write caches, uploads and generated assets there. Combine a writable application directory with a root-started process that loads something from it before the privilege drop, and the write primitive from a web vulnerability becomes a root execution primitive.
This is why the second CVE should not be read as "another Zammad bug". It is a packaging and startup-order defect that converts any code execution in the application into host compromise. Fixing the web flaw removes the first step. Fixing the startup order removes the amplifier, and it protects against the next web flaw too.
Detection is a session and process-tree problem
The first stage of the chain touches sessions, so the useful audit trail is not only the HTTP log. Review the session store for sessions created without a matching authentication event, and look for session identifiers reused across distinct source addresses.
The second stage touches the boundary between the service account and root. Process trees where a zammad-owned binary is a parent of a root process are worth explaining, and so are cron entries, systemd units, and rc files owned by the service account. File ownership drift in the application directory is the other signal: files that the service account can overwrite and that privileged code consumes.
The downstream stage is credential theft. A helpdesk integrates with mail, with object storage, with a directory, and often with a chat platform. Any credential reachable from the web server's user is compromised once the first stage succeeds, regardless of whether the second stage was attempted. Rotation is not optional after a confirmed session hijack, and it must include credentials that the application does not itself use but has stored for other purposes.
Remediation order
Patch the application, and then verify the startup order of the packaged service independently. If the vendor's fixed package changes when the process drops privileges, a version check on the application is sufficient. If the fixed package is not available for your platform, the mitigation is to stop running the service as root: bind the low port through a socket activation unit or a reverse proxy, run the daemon directly as the service account, and remove the writable-by-service-account path from anything root executes.
Zammad's own guidance, as relayed in reporting, recommends upgrading and treating a suspected compromise as an incident rather than a patch task, because a session hijack gives an attacker everything a legitimate administrator session had. For organisations that cannot move immediately, taking the instance offline is defensible. A helpdesk that is unavailable for a day is an inconvenience; a helpdesk that hands over a directory credential is a much larger problem.
The uncomfortable lesson
The organisation that was compromised spends its working hours telling other people to patch. Nothing about the incident suggests the response was slow, and nothing suggests the estate was neglected. What it suggests is that a product sitting in the middle of an identity graph, with a service account that can write to its own program directory, carries risk that a patch cadence cannot fully address.
References
NVD, CVE-2026-102489, https://nvd.nist.gov/vuln/detail/CVE-2026-102489
NVD, CVE-2026-102490, https://nvd.nist.gov/vuln/detail/CVE-2026-102490
FreeBuf analysis of the DIVD incident and the two-flaw chain, https://www.freebuf.com/articles/ai-security/504638.html
CISA Known Exploited Vulnerabilities catalog, https://www.cisa.gov/known-exploited-vulnerabilities-catalog