Zammad's packages ran as root and executed files the service account could write

CVE-2026-102490 is a local privilege escalation that reads more like a design review than an exploit. NVD records a CVSS 3.1 base score of 7.8 with the vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. CISA added it to the Known Exploited Vulnerabilities catalog on 2 October 2026.

The mechanism, as the advisory states it

Zammad packages built with packager.io, in DEB and RPM form, started service processes as root and had those processes execute files owned and writable by the unprivileged zammad account before dropping privileges to that account. A local attacker who already had file system write access as the zammad service account could therefore place content in a path that root would execute, and the next service restart would run it as root.
Two details make this worse than a generic "insecure file permissions" entry. The affected services were restarted automatically whenever they stopped, so no administrator had to log in and restart anything. And the escalation could complete within seconds, because the vulnerable window is the startup sequence itself.
Installations from source and from the official container images were not affected. Every released packaged version was.

Why the container distinction matters operationally

The advisory draws a clean line, and it should be read as a lesson about packaging rather than a footnote. The same application code behaved safely inside a container because the container's process model does not require root to launch and then drop privileges the same way. The packaged deployment inherited a pattern that was common a decade ago and that has been steadily removed from modern service units.
Teams that run Zammad from a package now face a specific question: which process start-up path does my deployment use, and who can write to the files it executes? A configuration file that is never executed is a low-value target. A helper script that runs as root and lives in a directory the service account owns is a launch pad.

What to check on a Zammad host

Start with the package version and the fixed build named in the vendor advisory. Then verify what actually runs at start-up rather than what the unit file claims. The paths worth auditing are the ones that combine three properties: executed during service start, owned by or writable by the zammad user, and reachable without an additional privilege boundary.
Look for world-writable or service-account-writable files in the application directory, in the directories the service unit references for environment files, and in any wrapper script the package installs. A file that the application writes as part of normal operation is not automatically suspicious; a file that the init sequence executes and the application can rewrite is.
Then check the restart policy. An automatic restart that fires on failure is a usability feature and an attack accelerator when the vulnerable step is start-up. Where the platform allows it, disable automatic restart during investigation so that a compromised foothold does not get repeated execution windows.

The lateral question

A local privilege escalation on a ticketing system matters because of what the ticketing system holds. Zammad stores customer email bodies, attachments, and the account metadata behind them. Root on the host means the application's database credentials, its session secrets, and its file store are all reachable.
If you find evidence of a foothold under the zammad account, the privilege escalation may already have happened and the visible artifacts may be gone. The durable evidence is in the timing: file creations immediately followed by a root-owned process start are anomalous in ways that ordinary application logging does not capture. Filesystem audit rules on the application directory, if you had them, are worth more than an application log review now.

The transferable point

Privilege drop is a sequence, not a state. A process that starts as root, reads a file, and then becomes an unprivileged user has to be deliberate about every file it touches before the drop. When that discipline is missing, the vulnerable asset is not the application but the moments between exec and setuid.
CVE-2026-102490 has a fix, and packaged deployments should take it. Deployments that already moved to containers or source installs should confirm that the reason for their exemption is architectural rather than accidental, because "we are not affected" is a claim about a start-up path, and start-up paths drift.

References

  • Zammad security advisory for CVE-2026-102489 and CVE-2026-102490, https://zammad.com/en/advisories/cve-2026-102489-cve-2026-102490

  • GitHub security advisory GHSA-p97w-927q-8vxq, https://github.com/zammad/zammad/security/advisories/GHSA-p97w-927q-8vxq

  • NIST NVD record for CVE-2026-102490, https://nvd.nist.gov/vuln/detail/CVE-2026-102490

  • CISA Known Exploited Vulnerabilities catalog entry, https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-102490