Zammad CVE-2026-84458

Exploitation requires that the 'Automatic account link on initial logon' setting is enabled AND at least one third-party SSO/identity provider is configured on the Zammad instance. The highest-impact and default-exploitable path is Zammad's out-of-the-box multi-tenant Microsoft 365 /common app registration, which trusts any Azure AD tenant, letting an attacker set an arbitrary email on an identity they control. The attacker must control any identity at a configured provider (their own account suffices - no Zammad credentials needed). Limiting factors: the auto-link setting must be on; instances that do not use SSO auto-linking are unaffected; and post-fix (7.1.2) admins who configure the 'email' and 'xms_edov' optional claims plus the new require_verified_email_domain strict setting are protected, though by default a missing xms_edov claim still preserves legacy linking behavior.

This is a genuinely high-priority authentication bypass, not a high-CVSS-but-low-risk artifact. The CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:N/VC:H/VI:H) accurately reflects a remote, unauthenticated attacker achieving high confidentiality and integrity impact via full account takeover - including agent and administrator accounts. The single mitigating dimension is AT:P (attack requirement present), which correctly captures that the 'Automatic account link on initial logon' setting must be enabled and an SSO provider configured. Critically, the description states that Zammad's DEFAULT multi-tenant Microsoft 365 /common app registration makes this exploitable by any Azure AD tenant worldwide, so the precondition is commonly met in real deployments rather than being an exotic configuration. No EPSS score, CISA KEV listing, or public POC is present in the provided data, so there is no evidence of active exploitation or automated weaponization - this is a serious latent risk rather than a confirmed in-the-wild campaign. The vendor patch is confirmed available (GHSA-86cc-3ggh-mf2m, commit 0dba387d), which both enables remediation and discloses the mechanism to would-be attackers.

An attacker registers or controls any identity in any Azure AD tenant (trivially possible against Zammad's default multi-tenant /common Microsoft 365 registration), sets that identity's email attribute to a target Zammad administrator's email address, and authenticates via SSO. Zammad matches the reported email to the existing local admin account without verifying the identity provider actually owns that email, logging the attacker in as the administrator and bypassing the local password entirely. No public exploit code is identified in the provided data, but the technique is straightforward given the disclosed fix.