Zammad CVE-2026-56733

Requires the attacker to already hold a valid but restricted/scoped Zammad access (API) token whose granular restrictions are intended to prevent administrative actions. Under this condition, the token's limits are overridden by the parent account's authorization authority during creation of new identity (user) objects, permitting creation of administrator accounts. Limiting factors: exploitation depends on possessing such a token (PR:L, not anonymous), the parent account backing the token must carry sufficient latent authority, and the instance must run a version prior to 7.0.2 / 7.1.0. No user interaction is required and the vector is network-reachable.

This is a genuine high-priority privilege-escalation flaw, not a high-CVSS-but-low-risk case. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N with VC:H/VI:H/VA:H, score 8.7) is internally consistent with the description: a network-reachable attacker holding only a low-privilege but valid access token can escalate to full administrator control, which is confirmed by both the vendor advisory (GHSA-p3mg-2jxr-hww2) and the patch commits. PR:L is well-supported - the attacker must already possess a restricted API token, so this is an authenticated escalation, not fully anonymous exploitation. No EPSS score, no CISA KEV listing, and no public exploit code were provided, so exploitation status is 'no public exploit identified at time of analysis' - treat as a patch-urgently item rather than an active-exploitation emergency. The commit diff and accompanying regression spec concretely confirm the root cause (stale @_user_on_behalf memoization allowing impersonation-state inheritance), which raises confidence that the flaw is real and reliably reproducible even though no weaponized POC is circulating. No key signals conflict; the main missing signals are EPSS/KEV/POC, whose absence lowers urgency but does not reduce the technical impact.

An attacker who has obtained a scoped/restricted Zammad API access token (e.g., a token intended only for limited ticket operations) issues a request to create a new user identity. Because the restricted token's granular limits are overridden by the parent account's latent administrative authority during identity initialization, the attacker creates a brand-new administrator account, then logs in with it to seize full control of all tickets, customers, and configuration. No public exploit code was identified, but the fix commit ships a regression test that demonstrates the exact stale-impersonation condition.