Description

ZITADEL 3.x before 3.4.15 and 4.x before 4.17.1 contains an improper authorization vulnerability: when issuing passkey or passwordless enrollment codes, it checks only the organization in the x-zitadel-orgid header, not the target user's organization. Attackers with user-write permission in one organization can obtain an enrollment code for a user in another organization on the same instance and register their own authenticator to take over that account.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.6",
  "pubDate": "2026-10-04T15:16:32.007Z",
  "pubdate": "2026-10-04T15:16:32.007Z",
  "executiveSummary": "ZITADEL versions 3.x prior to 3.4.15 and 4.x prior to 4.17.1 are susceptible to an improper authorization vulnerability concerning the issuance of passkey and passwordless enrollment codes.\nThe vulnerability resides in the validation logic responsible for cross-organizational requests. Specifically, the system incorrectly trusts the 'x-zitadel-orgid' header provided in the request rather than validating the target user's actual organization membership.\nThis flaw enables an attacker possessing user-write permissions within a single organization to initiate an unauthorized enrollment process for a victim user located in a different organization on the same instance.\nThe primary security implication is total account takeover. By successfully obtaining an enrollment code for a target user, an attacker can register their own authenticator as a valid credential for the victim's account, thereby bypassing existing authentication mechanisms.\nThe exploit requires the attacker to already hold legitimate write privileges within their own organization, allowing them to interface with the enrollment API. No administrative access to the global instance is required, making this a significant threat to multi-tenant ZITADEL deployments.",
  "technicalDetails": "The root cause of this vulnerability is a failure in the authorization check logic during the generation of passkey or passwordless enrollment codes. In a multi-tenant ZITADEL environment, the system must ensure that an entity requesting an enrollment operation for a target user has the appropriate authority within the scope of that specific user's organizational context.\nIn the affected versions, the authorization mechanism relies exclusively on the 'x-zitadel-orgid' header to establish organizational scope. The application fails to verify whether the target user identifier provided in the request actually belongs to the organization specified in the header. Consequently, the input is treated as authoritative, leading to an insecure direct object reference (IDOR) type behavior in the authorization layer.\nThe attack flow proceeds as follows: 1) An attacker with valid user-write permissions in 'Organization A' authenticates to the ZITADEL instance. 2) The attacker submits a request to the enrollment endpoint to generate an authentication token or enrollment code for a user identifier belonging to 'Organization B'. 3) The attacker includes the 'x-zitadel-orgid' header set to 'Organization A' (or an organization where they have permissions) to satisfy the initial API gateway check. 4) The backend process, failing to perform a secondary ownership verification against the target user's database record, assumes the request is legitimate and returns a valid enrollment code. 5) The attacker utilizes this code to register their own device or passkey for the victim's account. 6) Upon successful registration, the attacker gains full control over the target user account, effectively bypassing the intended security boundaries between tenants on the same instance.\nThis vulnerability effectively collapses the tenant isolation model regarding passwordless credential management. Because the enrollment code generation is the primary vector for establishing MFA/passwordless trust, the impact is critical, resulting in complete unauthorized access to the target account's resources, sensitive data, and potential lateral movement if the victim account holds higher privileges. The vulnerability is present in the core identity and access management functions of ZITADEL and remains exploitable as long as the application relies on unverified client-provided headers for authorization decisions regarding cross-tenant interactions."
}