CVE-2026-109372 in Zitadel
Summary
by MITRE • 10/12/2026
ZITADEL 4.x before 4.19.2 and 3.x through 3.4.15 contains an authentication bypass in the SAML identity-provider intent callback, which verifies the assertion signature using the provider named in the request URL but resolves the user from the login intent without checking they match. Attackers with organization-administrator permission can register a SAML provider with their own signing key to obtain authenticated sessions as any user linked to another SAML provider on the instance, including in other organizations.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/12/2026
The vulnerability identified within ZITADEL versions 4.x prior to 4.19.2 and 3.x through 3.4.15 represents a critical authentication bypass flaw located specifically in the Security Assertion Markup Language identity-provider intent callback mechanism. This component is responsible for processing incoming SAML assertions from external identity providers during single sign-on flows. The core technical deficiency lies in how the system validates the integrity of these assertions against its internal registry of trusted entities. When an assertion arrives, the application correctly verifies the cryptographic signature using the public key associated with the provider name extracted directly from the request URL parameters. However, the subsequent step of resolving the user identity fails to enforce a strict binding between that specific SAML provider and the login intent context initiated by the user or system. This logical disconnect allows an attacker to manipulate the flow such that the signature verification passes for one entity while the session is established under the credentials of another entirely different user linked to a separate service provider within the same instance.
This architectural flaw enables privilege escalation through identity spoofing, allowing attackers with organization-administrator permissions to exploit the trust relationship between ZITADEL and its configured SAML providers. An adversary possessing these elevated privileges can register a new SAML identity provider configuration under their control, supplying it with a custom signing key pair that they possess the private keys for. By crafting malicious authentication requests that reference this newly registered provider in the URL while simultaneously manipulating the underlying intent context to point toward a target user associated with a legitimate, trusted third-party SAML provider, the attacker can bypass standard access controls. The system accepts the assertion as valid because the signature matches the attacker-controlled provider, yet it assigns the session privileges and identity attributes of the unsuspecting victim from the other organization or service provider. This effectively grants the attacker full administrative control over the target user account without requiring knowledge of their password or multi-factor authentication secrets.
The operational impact of this vulnerability is severe, as it compromises the fundamental integrity of the identity federation architecture. Attackers can assume the identity of any user linked to a SAML provider on the instance, including those residing in distinct organizations within the same ZITADEL tenant. This capability facilitates unauthorized access to sensitive data, lateral movement across organizational boundaries that are typically isolated by design, and potential manipulation of business-critical workflows dependent on accurate user attribution. The ability to impersonate other users undermines audit trails and accountability mechanisms, as actions performed under the attacker-controlled session will appear to originate from legitimate identities. This poses significant risks for enterprises relying on ZITADEL for centralized identity management, particularly in multi-tenant environments where strict separation of duties and organizational boundaries are required for compliance with data protection regulations such as GDPR or HIPAA.
From a classification perspective, this vulnerability aligns closely with CWE-287 Improper Authentication, specifically regarding the failure to verify that the authenticated entity matches the intended context. It also reflects aspects of CWE-345 Insufficient Verification of Data Authenticity, where the system verifies one aspect of data integrity (the signature) but neglects another critical aspect (the binding between provider and user intent). In terms of offensive security frameworks, this exploit technique maps to ATT&CK T1078 Valid Accounts, as it involves using legitimate credentials or permissions in an unauthorized manner, and potentially T1556 Modifying Authentication Process if the attacker modifies configurations to facilitate future attacks. The exploitation relies on logical flaws rather than buffer overflows or injection techniques, making static analysis tools less effective at detection without specific logic-aware scanning capabilities.
Mitigation strategies must prioritize immediate software updates as the primary defense vector. Organizations running affected versions of ZITADEL should upgrade immediately to version 4.19.2 for the v4 branch or version 3.4.15 for the v3 branch, where this logical binding issue has been resolved by enforcing strict correlation between the SAML provider identifier and the user resolution logic. Until patching is feasible, administrators with organization-level privileges should be restricted to minimize the attack surface, as only users with such permissions can register new identity providers required for exploitation. Implementing rigorous change management processes that require peer review or automated validation of any modifications to identity provider configurations can also serve as a compensating control. Furthermore, enhancing monitoring and logging around SAML assertion processing events may help detect anomalous patterns indicative of this bypass attempt, although the primary remediation remains applying the vendor-provided security patch to close the logical gap in the authentication flow.