Exploited Zammad helpdesk chain runs from session hijack to root

Two flaws in Zammad, the open-source helpdesk and ticketing platform deployed on Linux and Docker hosts, are being used in attacks. CISA added both to its Known Exploited Vulnerabilities (KEV) catalog on 2 October and gave federal agencies until 5 October to act. Used together, they take an attacker from no account at all to root on the server that holds an organisation’s support tickets.

Two bugs, one path to the operating system

The first entry, CVE-2026-102489, is a session fixation weakness (CWE-384). An attacker who gets a user’s session into a state they control can ride that session into remote code execution, landing as the unprivileged service account the application runs under. The CVE record, published on 30 September by the Dutch Institute for Vulnerability Disclosure (DIVD) acting as the assigning authority, scores it 8.7 under CVSS 4.0 on its own. The vector needs no credentials, only passive involvement from a legitimate user.

The second, CVE-2026-102490, is an improper privilege management flaw (CWE-269). It lets that same local service account become root. Alone it is rated 8.5, because it needs a foothold on the host first.

The point of listing them together is the combination. Both CVE records carry a separate chained score of 9.4, Critical, for the full sequence: network reachable, no privileges, and total loss of confidentiality, integrity and availability on the server and beyond it. CISA’s own catalog entries say each flaw can be chained with the other.

What the government sources confirm

• Active exploitation. CISA added both entries on evidence of exploitation in the wild. Its SSVC assessment in the CVE records marks exploitation as active and technical impact as total for both. It rates the remote session hijack as automatable; the root escalation is not, since it depends on access already gained.
• A three-day federal window. The due date of 5 October falls three days after listing. Binding Operational Directive 26-04 directs agencies to remediate quickly when a catalogued flaw sits on a publicly exposed asset and exploitation grants total control of it.
• Forensic triage is required. Both entries are flagged for forensic triage. CISA’s implementation guidance asks agencies to scope the affected systems quickly, capture volatile evidence such as memory before changing the host, and only then patch, contain and look for persistence or lateral movement. Patching first can destroy the evidence of whether the server was already taken.
• Ransomware use is unknown. The catalog does not tie either flaw to a ransomware campaign, and neither CISA nor the CVE records say who is behind the attacks or how many servers have been hit.

Gaps and inconsistencies defenders should know about

The version data in the public records does not line up cleanly, so treat any single version number with care.

For the session hijack, the CVE record’s structured data lists releases from 6.3.0 up to, but not including, 6.5.4 as affected and the 7.x line as unaffected, while its written description names 6.5.4 itself and says the bug also exists in 7.0.0 through 7.1.3 but cannot be exploited there because of how those releases are set up. NVD’s own analysis goes further and marks 7.0.0 through 7.1.3 as vulnerable. “Not exploitable here” is a narrower claim than “not affected”, and it could change if a deployment differs from the default.

For the root escalation, the gap is wider. The structured range runs from 1.5.0 up to a 7.1.0 alpha, while the written description says every release, including the newest alpha at the time of disclosure, is affected. Neither record names a fixed release, and the catalog points readers to the vendor’s release notes rather than stating one.

What is not public yet: how attackers are planting the fixed session, whether hosted Zammad instances are exposed in the same way as self-managed ones, and any indicators of compromise.

What to do, in order

1. Find every Zammad instance, including test and forgotten ones, and note which are reachable from the internet. The remote half of the chain needs network access to the web interface.
2. Run a compromise check before you upgrade. Following CISA’s triage approach, preserve memory and logs from exposed hosts, then look for unexpected processes or files owned by the service account, new root-level persistence, and odd sessions in the application logs.
3. Upgrade using the vendor’s current release notes, and confirm the installed release covers both CVEs rather than relying on one record’s version range.
4. If you cannot upgrade at once, restrict access. Put the web interface behind a VPN or an allowlist of trusted addresses, and treat the server as untrusted until the check in step 2 comes back clean.
5. Rotate secrets the server could reach: mail account credentials used for ticket intake, API tokens for connected systems, and database passwords. A root shell on a helpdesk host exposes all of them.
6. Review ticket data exposure. Support queues often hold customer personal data and internal credentials pasted by users. If you find signs of compromise, involve your privacy and legal teams early.

Organisations outside the US federal government are not bound by the 5 October date. The conditions behind it still apply to any exposed Zammad server: attacks are confirmed, the chain ends in full control, and the first step can be automated. Other actively exploited flaws are indexed in the CVE search.

Source: Cybersecurity and Infrastructure Security Agency (CISA)