CVE-2026-102490: Zammad Privilege Escalation

Root Cause

The root cause is an unsafe relationship between service startup privileges, executable ownership, and installation-directory permissions in affected packaged deployments. The affected service processes initially run as root, execute files owned and writable by zammad, and then drop privileges to the unprivileged service account. If an attacker can replace or modify those files, the altered content may execute during a privileged service start or restart.

This design becomes particularly dangerous because the affected services restart automatically when they stop. An attacker does not necessarily need an administrator to manually restart Zammad. By stopping or triggering a service restart after modifying the relevant content, the attacker may cause code under their control to execute with root privileges.

The exploitation sequence described by the available records is:

1. Obtain filesystem-write capability as zammad.
2. Modify executable content or another file used during privileged service startup.
3. Trigger or wait for an automatic service restart.
4. Allow the modified content to execute before the service drops privileges.
5. Obtain root-level access to the host.

The vulnerability represents a privilege-boundary failure rather than a direct network attack. The initial access path remains important: defenders should investigate how an attacker could write as zammad, not only whether the vulnerable package is installed.

Technical Notes

A basic local review should identify the service account, installation paths, and ownership of executable files. Run these commands as an administrator and adapt paths to the distribution’s package layout:

getent passwd zammad
systemctl list-units --type=service | grep -i zammad
systemctl cat zammad
ps -eo user,group,pid,ppid,comm,args | grep -i '[z]ammad'

Inspect package ownership and writable paths:

dpkg -l | grep -i zammad
rpm -qa | grep -i zammad

find /opt/zammad /usr/share/zammad /var/lib/zammad \
  -xdev -type f -user zammad -writable -ls 2>/dev/null

find /opt/zammad /usr/share/zammad /var/lib/zammad \
  -xdev -type f -perm /022 -ls 2>/dev/null

The exact directories vary by package and operating system. Do not treat the absence of a result from these example paths as proof that a host is safe.

Who’s Exposed

The affected installation method is the most important scoping criterion. The vulnerability affects Zammad installed from DEB or RPM packages built with packager.io. The DIVD CSIRT advisory identifies the affected version range as Zammad v1.5.0 through v7.2.2 when installed through those package formats.

The GitHub security advisory gives a narrower boundary, listing affected versions as <= 7.2.1 and identifying 7.2.2 as the patched version. Because the available sources use different boundaries, organizations should not rely on a version-only conclusion without checking the package provenance and exact deployment method.

The NVD description states that all released packaged versions were affected, while the vendor advisory adds runtime-specific context: exploitation is possible in practice on Zammad 6.5 and earlier, and Zammad 7.0 and later are not affected in practice under the vendor’s runtime environment. These statements should be reconciled against the exact package, runtime, operating system, and service configuration in use.

Administrators should inventory both the Zammad version and how it was installed. A system may appear current in an application interface while still running an older package, a partially updated service component, or a custom package derived from an affected build.

Severity Breakdown

CVE-2026-102490 has a CVSS base score of 7.8, placing it in the high-severity category. The available NVD record does not expose the complete CVSS vector, so the precise values for attack complexity, privileges required, user interaction, scope, confidentiality, integrity, and availability should be obtained directly from the authoritative record before using them in automated scoring or risk dashboards.

The practical severity is driven by the resulting privilege level. The attacker begins with access associated with the unprivileged zammad account but can potentially reach root on the host. Root access can expose Zammad application data, credentials, configuration files, locally stored secrets, database access, backups, operating-system files, and other services on the same machine.

The local prerequisite reduces the set of directly exposed attackers compared with a remotely reachable unauthenticated flaw. It does not make the issue low risk. A separate vulnerability or compromised integration that enables writes as zammad can become a reliable path to full host compromise. The CISA KEV listing further indicates that attackers have successfully exploited the vulnerability in real-world environments.

Exploitation Status

Exploitation in the wild is confirmed by CISA’s KEV listing. CISA added CVE-2026-102490 on 2026-10-02 and assigned a remediation due date of 2026-10-05. The KEV record does not identify a specific threat actor, exploit kit, campaign, or intrusion set.

CISA records the ransomware-campaign field as Unknown. The available KEV data does not associate this vulnerability with a known ransomware campaign; it does not mean that ransomware involvement has been ruled out across all environments.

No standalone public proof-of-concept repository was identified in the reviewed references. The GitHub security advisory documents the issue and remediation but, based on the available material, does not provide an exploit repository. Defenders should distinguish between “no public PoC identified in the reviewed sources” and “no exploit exists.” The KEV status demonstrates that exploitation has occurred regardless of whether a public PoC is available.

Organizations with exposed or vulnerable deployments should assume targeted exploitation is plausible. Preserve evidence before making destructive changes if compromise is suspected, particularly where the zammad account may have written to executable paths or where unexpected root-level activity occurred.

Sources

The primary references for this assessment are:

1. NVD: CVE-2026-102490
   Provides the CVE description, CVSS base score, affected installation context, and publication metadata.

2. CVE Record: CVE-2026-102490
   Provides the CVE record and coordinator information.

3. CISA Known Exploited Vulnerabilities Catalog
   Records the KEV listing, 2026-10-02 date added, 2026-10-05 due date, and unknown ransomware-campaign status.

4. Zammad vendor advisory
   Provides vendor-specific impact and runtime context.

5. GitHub Security Advisory: GHSA-p97w-927q-8vxq
   Identifies affected versions as <= 7.2.1 and patched version 7.2.2.

6. DIVD CSIRT advisory for CVE-2026-102490
   Identifies the broader affected range of Zammad v1.5.0 through v7.2.2 for DEB and RPM installations.

7. DIVD case DIVD-2026-00015
   Provides additional coordinator case context.

For related terminology, see our cloud security glossary.

Where these sources differ on version boundaries or runtime conditions, administrators should use the conservative operational position: identify package provenance, upgrade packaged installations to Zammad 7.2.2 or later, verify the resulting service configuration, and investigate systems that ran affected versions.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.