Local privilege escalation to root in Zammad DEB and RPM packages from Zammad GmbH

Zammad packages built with packager.io (DEB and RPM) could have allowed a local attacker who already had file system write privileges as the unprivileged zammad service account to escalate to full root privileges on the host. Service processes began running as root and executed files that were owned and writable by the zammad account before dropping their identity to that account. An attacker holding that foothold could have escalated within seconds, because the affected services were restarted automatically whenever they stopped; no administrator interaction was required. Only installations from the DEB and RPM packages were affected; installations from source or the official container images were not. All released packaged versions were affected.

• Zammad on Linux installed from packager.io-built DEB or RPM packages is affected at versions >= 1.5.0 and < 7.2.2. The affected record describes all released packaged versions in this interval as affected.
• Versions < 1.5.0 and >= 7.2.2 are marked unaffected in the structured affected data.
• Source installations and official container images are not affected by this packaging issue.
• The vendor's GitHub advisory identifies 7.2.2 as the patched version.

Zammad GmbH Zammad packages built with packager.io contain an unsafe service startup and file execution arrangement. Service processes began running as root, executed files owned and writable by the zammad service account, and only then dropped their identity to zammad. An attacker who already had code execution or filesystem write access in the zammad context could therefore alter a file used by the privileged process and wait for the service to restart. The affected services restarted automatically when stopped, so administrator interaction was not required. Public material does not identify the service names, exact paths, or specific service-manager units involved; those details must be verified on each installation.

This is a local privilege escalation issue. The attacker must already have access to the underlying host and filesystem write privileges as the zammad service account; the vendor states that the issue cannot be exploited remotely on its own. Once that foothold exists, changing a file and triggering the automatic service restart requires no administrator interaction and can complete within seconds. DIVD reports that the vulnerability was abused in a breach of its own Zammad system, confirming exploitation beyond a theoretical scenario. The supplied record marks the issue as known exploited and publicly exploitable; the reviewed material does not identify a named tool, payload, or exploit artifact.

• The technical result is escalation from write or execution access in the zammad account context to root on the same host.
• root access can allow reading, modifying, or deleting operating-system data and files, changing configuration, controlling Zammad services, and making the host unavailable.
• The direct scope described by the sources is the host containing the installation; the available evidence does not show that this issue automatically compromises other systems.
• Because an initial host foothold is required, this is not an independent remote takeover. However, if that foothold comes from another vulnerability or access channel, the escalation can turn limited access into control of the entire host.

A successful exploit can provide root access to the host running Zammad, allowing an attacker to modify system files, control service processes, and disrupt the host or the support service. Data, configuration, and local resources accessible to root may be read, changed, or deleted. The organization may need to investigate host integrity, contain the affected service, and recover operations. The available evidence does not establish what data was accessed in any particular deployment.

1. Update DEB or RPM installations to Zammad 7.2.2, which the vendor advisory identifies as patched. After updating, verify the actual package source and running version.
2. If an immediate update is not possible, restrict access to the underlying server to trusted administrators only. This is containment, not a fix, and does not remove attacker write access that may already exist.
3. Because exploitation has been reported, investigate affected hosts before treating them as trusted. Review Zammad logs, installation-file integrity, and privileged changes on the host; the DIVD-published log check script can support the log review.
4. If compromise is suspected, follow the organization's incident-response process, including assessing credentials and data that may have been exposed. DIVD does not document a specific workaround beyond updating or restricting server access.

1. Inventory Zammad systems and identify whether each installation came from DEB/RPM packages, source, or official container images. The described exposure is limited to the DEB/RPM installations.
2. Check the version of every DEB/RPM installation and compare it with the boundaries in affected_summary.
3. Review ownership and write permissions for the installation directory, files executed by the services, and related configuration files. Look for files that zammad can modify while a privileged service can execute them.
4. Inspect service definitions and process behavior to determine whether services start as root and then drop to zammad, and review the configured automatic restart behavior.
5. Review Zammad logs with the log check script published by DIVD when investigating possible compromise. Unexpected restarts and unexplained changes to installation files can be treated as precautionary signals, not as confirmed indicators of compromise.
6. Do not treat the absence of suspicious log evidence as proof that a system is safe.