CVE-2026-105206 in Zitadel
Summary
by MITRE • 10/04/2026
ZITADEL 3.0.0 through 3.4.15 and 4.x before 4.17.3 contains an incorrect authorization flaw in the User Service API, which verifies user.read against the caller's organization rather than the organization owning the target user. An authenticated member holding org-scoped user.read can query GET /v2/users/{userId}/authentication_methods to learn which authentication method types users in other organizations have registered.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/04/2026
The vulnerability identified as a broken access control flaw within ZITADEL versions 3.0.0 through 3.4.15 and 4.x prior to version 4.17.3 represents a critical failure in the enforcement of authorization policies for multi-tenant identity management systems. This specific issue resides in the User Service API, where the system incorrectly validates permissions against the caller's organization rather than the organization that owns the target user resource. In typical zero-trust or role-based access control models designed for Software-as-a-Service platforms, an authenticated member should only be able to perform actions on resources within their own tenant boundary unless explicitly granted cross-tenant privileges. However, in this flawed implementation, the authorization check fails to isolate the scope of the request properly, allowing a user with org-scoped permissions to bypass organizational boundaries and access data belonging to other tenants.
The technical mechanism of exploitation involves an authenticated attacker who possesses the user.read permission within their own organization. By leveraging this valid credential set, the attacker can issue HTTP GET requests to the endpoint /v2/users/{userId}/authentication_methods for any arbitrary userId in the system. Because the backend logic verifies that the caller has read access relative to their own org rather than checking if they have access to the specific user's org, the API returns sensitive metadata about authentication methods registered by users in other organizations. This includes details such as whether a target user has configured multi-factor authentication, passwordless login options like WebAuthn or FIDO2, SMS verification, email-based magic links, or third-party identity provider integrations. The flaw essentially treats all users within the global system as accessible to any authenticated member with basic read privileges, ignoring the fundamental isolation principles required in SaaS environments.
The operational impact of this vulnerability is significant for both privacy and security posture across the entire ecosystem. From a confidentiality perspective, it constitutes an unauthorized information disclosure that violates data sovereignty expectations often mandated by regulations such as GDPR or HIPAA when cross-border tenant data is involved. Attackers can perform reconnaissance to map out which users in other organizations have enabled stronger authentication mechanisms versus those relying solely on passwords. This intelligence gathering facilitates targeted phishing campaigns known as spear-phishing, where attackers tailor their social engineering tactics based on the specific authentication methods available to a victim. For instance, knowing that a target uses SMS-based two-factor authentication allows an attacker to initiate SIM-swapping attacks or intercept codes via SS7 vulnerabilities more effectively than if they were unaware of this configuration.
Furthermore, this flaw undermines the trust model inherent in identity providers like ZITADEL. Organizations rely on these platforms to enforce strict isolation between tenants, ensuring that one customer's data remains invisible to another. The ability for any authenticated user to probe authentication configurations across organizational lines creates a persistent attack surface where adversaries can profile high-value targets within partner or competitor organizations without needing direct access credentials for those specific accounts. This level of visibility into security controls enables attackers to prioritize their efforts against users with weaker security postures, thereby increasing the overall risk of account compromise and subsequent lateral movement within affected enterprise networks.
To mitigate this vulnerability, administrators must upgrade ZITADEL to version 4.17.3 or later, where the authorization logic has been corrected to properly validate that a caller's permissions apply specifically to the organization owning the target user resource. Until an upgrade is performed, organizations should review their access control policies and consider implementing additional network-level restrictions if possible, although software patching remains the primary remediation strategy. Security teams should also audit logs for unusual patterns of GET requests to the authentication methods endpoint from users who do not have a business reason to interact with external tenants. Monitoring for these specific API calls can help detect exploitation attempts in real-time and trigger incident response procedures before significant data exposure occurs.
This vulnerability aligns closely with CWE-284, which describes Improper Access Control, specifically the failure to enforce proper restrictions on authorized individuals or processes regarding access to system resources. It also maps directly to MITRE ATT&CK technique T1087, Account Discovery, as it allows an attacker to enumerate user attributes and configurations across multiple accounts. Additionally, because it involves gathering information about authentication methods which aids in planning further attacks against specific users, it relates to reconnaissance activities categorized under initial access or credential access preparation phases of the cyber kill chain. Addressing this issue requires not only a software update but also a review of how organizational boundaries are enforced at the API gateway and service level to ensure that multi-tenant isolation is maintained rigorously across all endpoints.