CVE-2026-84458 in Zammad
Summary
by MITRE • 09/25/2026
Zammad is a web based open source helpdesk/customer support system. Prior to 7.1.2, when the "Automatic account link on initial logon" setting is enabled, Zammad binds an incoming third-party (SSO) identity to an existing local account by matching the email address the identity provider reports, without verifying that the provider actually confirmed ownership of that email. An attacker who controls any identity at a configured provider, including, by default, any Azure AD tenant via Zammad's multi-tenant Microsoft 365 /common app registration, can set that identity's email to a victim's address, authenticate, and be logged in as the victim. This bypasses the victim's local password entirely and affects any existing account, including agents and administrators. Zammad will honor the xms_edov ID token claim when email verification is required in the Microsoft 365 setting, treating a missing claim as unverified. This issue is fixed in version 7.1.2.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/25/2026
The vulnerability identified in Zammad prior to version 7.1.2 represents a critical authentication bypass rooted in flawed identity verification logic within the system's single sign-on integration mechanisms. Specifically, when the configuration option for automatic account linking on initial logon is enabled, the application attempts to map an incoming third-party identity from a configured provider to an existing local user account based solely on email address matching. This process fails to validate whether the identity provider has actually verified ownership of that specific email address before performing the binding operation. Consequently, the system trusts the email attribute provided by the external authentication service without requiring independent proof of control over that email domain or address from a trusted source within Zammad itself.
The operational impact of this flaw is severe because it allows an attacker to hijack any existing account in the Zammad instance, including high-privilege roles such as agents and administrators. By controlling an identity at a configured provider, an adversary can simply set that identity's email address to match that of their target victim. Upon authentication with the external provider, Zammad will automatically link this controlled identity to the victim's local account due to the matching email string. This effectively bypasses the need for the victim's password entirely, granting the attacker full access to the compromised account as if they were the legitimate user. The risk is further amplified by default configurations; notably, Zammad utilizes a multi-tenant Microsoft 365 application registration with the common endpoint by default. This means that any Azure AD tenant can be used to authenticate against this instance, significantly expanding the attack surface and allowing attackers from unrelated organizations to exploit the vulnerability if they have access to an account within their own Azure AD environment.
Technical analysis reveals that while Zammad attempts to mitigate this risk for Microsoft 365 integrations by honoring the xms_edov ID token claim which indicates email verification status, the implementation contains a logical flaw where a missing or null value in this claim is treated as unverified rather than being rejected or handled securely. This misinterpretation allows attackers to bypass verification checks if they can manipulate how the identity provider returns these claims during the authentication flow. The vulnerability aligns with CWE-287, which describes Improper Authentication, specifically relating to the failure to verify credentials properly before granting access. Furthermore, this exploitation technique maps directly to MITRE ATT&CK tactic T1078, Valid Accounts, and more specifically sub-technique T1078.004, Cloud Accounts, as it involves abusing legitimate cloud identity configurations to gain unauthorized access to on-premises or hosted applications without needing valid local credentials for the target account.
To mitigate this vulnerability, organizations running Zammad versions prior to 7.1.2 must upgrade immediately to version 7.1.2 or later where the logic has been corrected to properly enforce email ownership verification before linking accounts. In environments where upgrading is not immediately feasible, administrators should disable the automatic account linking feature on initial logon and instead require manual review and approval for new identity associations. Additionally, reviewing the Microsoft 365 application registration settings to restrict access to specific tenants rather than using the common multi-tenant endpoint can reduce the likelihood of exploitation by external actors. Regular audits of user accounts linked via single sign-on should also be conducted to detect any unauthorized bindings that may have occurred prior to remediation.