Zammad EUVD-2026-90081

Exploitation requires an existing local foothold as the 'zammad' service account (the OS user running the Zammad application) - the attacker must already be able to execute commands as that unprivileged account, typically obtained via a prior web-app compromise or credential access. All installations from Zammad 1.5.0 up to (but not including) 7.1.0-alpha are affected, so version is not a limiting factor until the fixed release is applied. The principal limiting factor is the prerequisite local access: despite the vendor CVSS 4.0 marking AV:N/PR:N, the description confines the attacker to an already-present local/service-account context, so this is not a remote unauthenticated exploit against a default network-facing configuration.

Signals conflict sharply and must be reconciled before prioritization. The vendor-supplied CVSS 4.0 vector (9.4) encodes AV:N/PR:N/UI:P - network, unauthenticated, passive user interaction - yet the description states the flaw lets 'the local zammad user escalate privileges to root,' which is a LOCAL privilege-escalation requiring an existing foothold as the zammad service account. These are inconsistent: a genuine local privesc should be AV:L/PR:L, which would score materially lower. The 9.4 rating therefore likely overstates real-world exposure; the realistic hazard is post-compromise escalation, not remote drive-by RCE. Treat the AV:N/PR:N as unverified and confirm with DIVD/vendor. Exploitation status: no CISA KEV listing and no EPSS provided, so per policy there is no public exploit identified at time of analysis - however, the vendor's own 4.0 vector carries the threat metric E:A (Exploit Maturity = Attacked), which hints at observed attack activity; this is a vendor claim, not CISA-confirmed active exploitation, and should be validated rather than assumed. A patch is available, which is the decisive risk-reducer here. Net: this is a real and serious issue for any host where an attacker can reach the zammad account (e.g., via a separate web-app compromise), but the headline 9.4 likely reflects a mis-scored vector rather than trivial remote exploitation.

An attacker who has already gained code execution as the unprivileged 'zammad' service account - for instance through a separate web-application flaw or a leaked credential - abuses the escalation weakness to obtain root on the host, gaining full control of the server and all tenant ticket data. No public proof-of-concept is identified at time of analysis, though the vendor's CVSS threat metric suggests attack activity may exist. Given AV:L/AC:L in the realistic (local) interpretation, escalation is straightforward once the initial foothold is present.