CVE-2026-102490 — Zammad GmbH Zammad Improper Privilege Management Vulnerability

CVE-2026-102490

Zammad - Local Privilege Escalation from the zammad Service User to root

What is Zammad?

Zammad is an open-source helpdesk and ticketing platform built on Ruby on Rails, typically self-hosted on Linux or run in Docker. It consolidates email, web forms, chat and phone enquiries into one agent-facing queue and ships with role-based permissions, a REST API and background job workers. The vendor cites more than 2,000 customers and 55,000 users.

Self-hosted Zammad runs its application processes under a dedicated unprivileged service account, conventionally named zammad. That separation is the security boundary this vulnerability breaks. An attacker who reaches code execution in the web tier is supposed to be confined to that account; a reliable escape to root turns an application compromise into full host ownership, including access to every other service and credential on the machine.

Overview

CVE-2026-102490 is an improper privilege management flaw that allows a local zammad user to escalate to root. CISA added it to the Known Exploited Vulnerabilities catalog on 2026-10-02 alongside CVE-2026-102489, with a remediation deadline of 2026-10-05.

It is the second stage of the chain used against the Dutch Institute for Vulnerability Disclosure on 2026-09-21. CVE-2026-102489 delivered code execution as the zammad service user over the network; this flaw converted that into root on the helpdesk host. DIVD reports the transition took seconds.

This entry carries a genuine, unresolved dispute between the finder and the vendor, and operators should plan around it. DIVD states the flaw affects effectively every Zammad release from 1.5.0 through 7.1.0-alpha and that it was used in a live intrusion. Zammad has publicly responded that it has not been shown technical details for this issue and therefore cannot verify the claim or its scope, saying it cannot verify a claim it has not been shown. As a result there is no confirmed fixed version for the privilege escalation itself. Reporting at the time of the KEV listing described the root flaw as unpatched.

Affected Versions

Product Vulnerable Fixed
Zammad (self-hosted, Linux and Docker) 1.5.0 through 7.1.0-alpha, per DIVD No vendor-confirmed fix for this CVE
Zammad Scope not confirmed by the vendor 7.2.0 recommended as the general upgrade target

The practical guidance from both parties converges on upgrading to 7.2.0 even though the vendor has not acknowledged a specific fix for this issue, because 7.2.0 blocks the network-facing first stage of the chain. Zammad directs operators to its GitHub security advisories for any further update.

Technical Details

CWE-269, improper privilege management, means the software grants, assigns or retains privileges in a way that lets a lower-privileged context obtain higher ones. In plain terms, something that runs with elevated rights can be influenced by the unprivileged service account: a setuid binary, a helper script invoked by root, a scheduled job, a writable path consumed by a privileged process, or over-broad sudo rules in the deployment's own packaging.

Exploitation requires local access and minimal privileges, which in the observed chain was supplied by the web-tier RCE rather than by a shell user. That pairing is what makes a merely local bug critical here, and it explains the scoring spread: DIVD rates this issue 8.5 standalone and 9.4 as part of the chain, while NVD records CVSS 3.1 9.8.

Note that the NVD vector on this record, AV:N/PR:N/UI:N, describes a network-reachable, unauthenticated attack, which does not match a local privilege escalation requiring an existing foothold. Readers should treat the vector as provisional pending an NVD revision rather than as evidence that the flaw is directly remotely triggerable.

Because DIVD has withheld the mechanism and Zammad says it has not received it, no verified root-cause description is available. Any specific technique circulating publicly should be treated as unconfirmed.

Discovery

The vulnerability was found by the Dutch Institute for Vulnerability Disclosure during the forensic investigation of an intrusion into DIVD's own environment, tracked as DIVD-2026-00014, with the Zammad findings published as DIVD-2026-00015. Victor Pasman leads the case, working with researchers from DIVD and Merlon Security. DIVD reported to Zammad on 2026-09-24 and began notifying exposed operators on 2026-09-26.

Exploitation Context

Exploitation is confirmed through incident response rather than scanner telemetry: the flaw was recovered from the forensic record of a real attack, with DIVD as the known victim. DIVD has not disclosed what data was taken or to what end and is proceeding on an assume-breach footing.

Attribution points to an autonomous AI agent rather than a named threat actor. DIVD describes logs showing iterative, automated decision-making, with the attacker selecting each next step immediately after the previous action, and attack scripts containing self-justifying comments. It also characterises the intrusion as loud and very very messy, noting mistakes such as password spraying, and assesses that the agent was likely poorly trained or configured. It reached root in seconds regardless, which is the part operators should take seriously.

No public exposure counts for vulnerable instances have been published by Shadowserver, Censys or GreyNoise. Because this flaw is local, exposure is better measured as the number of hosts where the first-stage RCE is reachable, which DIVD's ongoing scanning is enumerating.

Remediation

  1. Upgrade to Zammad 7.2.0 to remove the network-reachable first stage of the chain. Be clear-eyed that this is not a vendor-confirmed fix for CVE-2026-102490 itself; it removes the practical delivery mechanism.
  2. Monitor Zammad's GitHub security advisories and the linked community thread for a confirmed fix, since the vendor is still disputing the report's details.
  3. Where an upgrade cannot be completed before the deadline, take the instance offline, which is DIVD's stated recommendation.
  4. Treat any compromised Zammad host as fully compromised at the root level. Rebuild rather than clean, and rotate every credential and key present on the machine, not just Zammad's.
  5. Review the host for privilege escalation footholds: audit sudo rules applying to the zammad account, look for setuid binaries and root-invoked helper scripts writable by the service user, and check scheduled jobs.
  6. Hunt for setuid-family calls from the service account, root-owned processes under the application process tree, interactive shells spawned by Zammad, and unexpected outbound connections, reviewing logs back to at least 2026-09-21.
  7. Federal civilian agencies must remediate by 2026-10-05 under the CISA KEV requirement. Given that no confirmed patch exists for this specific CVE, isolating or discontinuing the service is the compliant fallback where mitigations are unavailable.

Key Details

PropertyValue
CVE ID CVE-2026-102490
Vendor / Product Zammad GmbH — Zammad
NVD Published2026-09-30
NVD Last Modified2026-10-02
CVSS 3.1 Score9.8
CVSS 3.1 VectorCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
SeverityCRITICAL
CWE CWE-269 find similar ↗
CISA KEV Added2026-10-02
CISA KEV Deadline2026-10-05
Known Ransomware Use No

CVSS 3.1 Breakdown

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

Required Action

CISA BOD 22-01 Deadline: 2026-10-05. Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.

Timeline

DateEvent
2026-09-21Vulnerability chain used to breach DIVD's own Zammad instance
2026-09-22DIVD detects the intrusion and begins forensic analysis
2026-09-24Vulnerability reported to Zammad by DIVD
2026-09-26DIVD begins internet-wide scanning and victim notification
2026-09-30CVE published and the Zammad entry point publicly disclosed
2026-10-02Added to CISA Known Exploited Vulnerabilities catalog
2026-10-05CISA BOD 22-01 remediation deadline