Zammad session hijacking chain CVE-2026-102489 escalates to root remote code execution

From stolen session to full takeover

A write-up published on dev.to documents a two-stage attack against Zammad, the open-source ticketing and helpdesk platform, in which a hijacked user session serves as the starting point for complete server compromise. The incident involved the vulnerability disclosure group DIVD, whose own Zammad deployment was targeted using the chain, and whose report underpins much of the published detail.

How the two CVEs fit together

The first vulnerability, CVE-2026-102489, converts a stolen session into the ability to execute code under the zammad service account. According to the dev.to analysis, it requires no prior privileges — only what CVSS terms passive user interaction — and scores 8.7 on its own. The zammad account is deliberately unprivileged, so this first stage looks like a modest win for the attacker.

The second stage is what changes the picture. CVE-2026-102490 takes that local foothold and elevates it to root, scoring 8.5 in isolation, lower only because local access is a precondition. Combined, the pair carries a CVSS 4.0 rating of 9.4, Critical, and both components are flagged as exploited in the wild. Neither Zammad nor DIVD has published the underlying technical defect for either flaw, the write-up notes, so defenders should reason from documented preconditions rather than speculation about the bug class. What is documented is speed: DIVD reports the chain was automatable and that root access was reached within seconds.

What the attacker gains

The net effect is that an unauthenticated attacker on the network ends up with full control of the host. Per the dev.to analysis, that means ticket contents, chat transcripts and customer records become readable, configuration secrets can be harvested, and the machine can be used as a jumping-off point for further movement.

DIVD confirmed that data belonging to its volunteers was taken, including email addresses and possibly other contact details, and it warned that the information could support impersonation attempts.

Affected versions and exposure

According to the report, CVE-2026-102489 is exploitable on Zammad 6.3.0 through 6.5.4. Versions 7.0.0 to 7.1.3 contain the underlying flaw but are assessed as not exploitable because of environment conditions. The privilege escalation, CVE-2026-102490, spans a far wider range, from Zammad 1.5.0 up to the 7.1.0 alpha, and both Linux and Docker deployments are affected.

Overall exposure is hard to quantify. A ZoomEye query cited in the write-up, run on 2 October 2026, returned 11,977 Zammad instances — a product fingerprint rather than a count of confirmed vulnerable hosts, and a follow-up filter for the escalation CVE on vul.cve returned no indexed results.

What operators should do

DIVD's guidance, relayed by dev.to, is to upgrade to Zammad 7 or take the system offline; either action removes the remote entry point and breaks the chain. Notably, the escalation flaw reportedly remains in current releases, with a fix still in progress.

Beyond that, the write-up recommends running the published log-check script against Zammad logs, pulling the helpdesk off the public internet or tightly restricting access, rotating credentials on the host and adjacent systems, and isolating the server on the network. Because the initial beachhead was a session rather than a stolen password, it also argues for a dedicated review of session handling and logging.

Why it matters

Two lessons stand out for self-hosters. First, individual severity scores understate chains: session hijacking on its own rarely reads as critical, but paired with a local privilege escalation it delivers unauthenticated root, and the per-CVE numbers will never show that. Second, helpdesk platforms are unusually rich targets — they concentrate customer correspondence, internal notes and integration secrets on a single box, and DIVD's experience shows the fallout reaches people, not just infrastructure. Anyone running Zammad 6.3–6.5 with internet exposure should treat this as urgent, and even patched installations warrant the log check and credential rotation.