CVE-2026-102489

What is Zammad?

Zammad is an open-source helpdesk and customer support ticketing platform written in Ruby on Rails. Organisations run it to triage email, web forms, chat and phone enquiries into a single ticket queue, with agent accounts, role-based permissions and a REST API. Zammad's own site cites more than 2,000 customers and 55,000 users, and the project is widely self-hosted on Linux and in Docker.

A ticketing system is an unusually rich target. It sits on the public internet by design, because customers and partners need to reach it, and it accumulates exactly the material an intruder wants: support correspondence, email addresses, attachments, internal notes and credentials pasted into tickets. For a vulnerability disclosure organisation it also holds unreleased vulnerability reports. Compromising the helpdesk therefore yields both a foothold and an archive.

Overview

CVE-2026-102489 is a session fixation flaw that lets an unauthenticated, network-based attacker take over a Zammad user session and from there execute code as the zammad service account. CISA added it to the Known Exploited Vulnerabilities catalog on 2026-10-02 with an unusually short remediation deadline of 2026-10-05.

The flaw became public because it was used against the Dutch Institute for Vulnerability Disclosure (DIVD). On 2026-09-21 an intruder chained this vulnerability with CVE-2026-102490, a local privilege escalation, and moved from a hijacked session to root on DIVD's helpdesk host. DIVD detected the activity the following day and published its findings as case DIVD-2026-00015, derived from the investigation of its own breach, DIVD-2026-00014.

Severity scoring differs between sources, and it is worth stating plainly. NVD records CVSS 3.1 9.8. DIVD scored this issue 8.7 on CVSSv4 standalone and 9.4 for the full chain with CVE-2026-102490. The practical reading is the same either way: no credentials are required and the entry point is the public web interface.

Affected Versions

Zammad states that 7.0 and later are not affected in practice and attributes the exposure to the runtime environment used by older releases. DIVD and the vendor agree on the upgrade target: move to version 7, and specifically to 7.2.0, which contains the hardening work.

Technical Details

Session fixation, CWE-384, is the class of bug where an application accepts a session identifier supplied or influenced by an attacker rather than issuing a fresh one at the point of authentication. If the identifier that a victim ends up authenticating with is a value the attacker already knows, the attacker inherits the authenticated session without ever learning a password.

In this case the hijacked session is the first stage of a two-stage chain. Once the attacker holds a valid session, the flaw is leveraged to reach command execution in the context of the zammad service user, which owns the application files and the database connection. Neither privileges nor credentials are required to begin, and attack complexity is rated low. Reporting indicates some passive user interaction is involved in landing the fixed session, which is consistent with the session fixation pattern.

Zammad has not published a detailed root-cause write-up, and DIVD has withheld exploitation specifics while instances remain unpatched. Treat any more precise mechanism described elsewhere as unconfirmed.

Discovery

The vulnerability was discovered by the Dutch Institute for Vulnerability Disclosure while investigating an intrusion into DIVD's own infrastructure, not through routine code review. Case DIVD-2026-00015 is led by Victor Pasman, with researchers from DIVD and Merlon Security. DIVD reported the issue to Zammad on 2026-09-24, three days after the attack it analysed, and began notifying exposed operators on 2026-09-26.

Exploitation Context

Exploitation is confirmed, in the strong sense that the vulnerability was identified by reverse-engineering a real intrusion rather than inferred from telemetry. The confirmed victim is DIVD itself. DIVD has not yet detailed which data was accessed or why it was exfiltrated, and says it is working on an assume-breach basis.

The notable feature of the intrusion is the attacker's apparent use of an autonomous AI agent. DIVD reports that each action was followed immediately by a self-selected next step, that the path from hijacked session to root took seconds, and that the operation was nonetheless, in its words, loud and very very messy, including password spraying that undercut the attacker's own stealth. DIVD's assessment is that the agent was poorly trained or configured yet still reached root, which left substantial forensic evidence behind.

No public scan data from Shadowserver, Censys or GreyNoise gives a count of exposed vulnerable instances at the time of writing; DIVD's own scanning and notification effort, begun 2026-09-26, is the only enumeration in progress. Chaining with CVE-2026-102490 is the expected path, since this flaw alone yields only the unprivileged service account.

Remediation

1. Upgrade to Zammad 7.2.0. This is the version carrying the hardening for this issue and the vendor's recommended target; 6.x receives no fix.
2. If an immediate upgrade is not possible, take the instance offline. This is DIVD's explicit recommendation and is proportionate given active exploitation and a three-day KEV deadline.
3. Assume compromise on any 6.3.0 to 6.5.4 instance that has been internet-facing, and run DIVD's indicator-of-compromise script (cve-2026-102489_ioc_check_script_v2.sh) against the host before returning it to service.
4. Hunt for the behavioural indicators: Zammad application processes spawning interactive shells, setuid-family calls from the service account, root-owned child processes under the application tree, and unexpected outbound connections from the helpdesk host.
5. Invalidate all active sessions and rotate secrets after patching. Session fixation leaves valid hijacked sessions behind, so a patch alone does not evict an attacker. Rotate API tokens, the Rails secret key base, and any credentials stored in or pasted into tickets.
6. Restrict the administrative interface to known networks or place it behind a VPN where the business allows it, and review web logs back to at least 2026-09-21 for anomalous session activity.
7. Federal civilian agencies must remediate by 2026-10-05 under the CISA KEV requirement. Given the short window, treat removal from the internet as the fallback if patching cannot complete in time.