CVE-2026-105208 in Zitadel
Summary
by MITRE • 10/04/2026
ZITADEL 4.x before 4.17.3 and 3.x through 3.4.15 protects IdP intent tokens with unauthenticated, malleable encryption, allowing authenticated users to tamper with their own token so it is accepted for another user's external login intent. An attacker who predicts a victim's in-flight intent identifier and wins a timing race can call /v2/idp_intents or /v2/sessions to steal the victim's IdP tokens or hijack their session.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/04/2026
The vulnerability identified in ZITADEL versions 4.x prior to 4.17.3 and 3.x through 3.4.15 represents a critical failure in cryptographic implementation within the identity provider integration workflow. The core technical flaw lies in the protection mechanism applied to Identity Provider intent tokens, which rely on encryption that lacks authentication of the ciphertext. This design choice means that while the data is encrypted, there are no integrity checks such as HMAC or authenticated encryption modes like AES-GCM to verify that the content has not been altered during transit or storage. Consequently, an attacker who possesses a valid token can manipulate its contents without detection because the decryption process will accept any syntactically correct ciphertext, regardless of whether it was generated by the server or modified by an external party.
This lack of integrity verification allows authenticated users to tamper with their own tokens in ways that subvert the intended access control logic. Specifically, an attacker can modify the token fields associated with a specific user identity to impersonate another victim. By altering these malleable encrypted values, the malicious actor can craft a request where the system believes the intent originates from or is authorized for a different user than the one making the API call. This manipulation effectively bypasses the authentication boundary, allowing the attacker to act on behalf of other users within the ZITADEL environment without possessing their actual credentials.
The operational impact of this vulnerability is severe due to the combination of token malleability and timing-based exploitation techniques. An attacker must predict a victim's in-flight intent identifier and execute a race condition attack against endpoints such as /v2/idp_intents or /v2/sessions. By winning this timing race, the attacker can intercept or manipulate the processing of these requests before they are fully validated by the server logic that might otherwise catch inconsistencies. Successful exploitation enables two primary malicious outcomes: the theft of sensitive Identity Provider tokens associated with external login intents and the hijacking of active user sessions. This leads to a complete compromise of user identity, potentially granting unauthorized access to connected services and exposing personal data stored within those integrated systems.
From a classification perspective, this vulnerability aligns with CWE-347 Improper Verification of Cryptographic Signature, as it involves failing to verify the authenticity or integrity of encrypted data before processing it. Furthermore, the exploitation technique involving timing races correlates with ATT&CK Tactic TA0001 Initial Access and specifically techniques related to session hijacking such as T1528 Steal Application Access Token. The ability to manipulate tokens also touches upon CWE-640 Weak Key Management if the encryption keys are not rotated or managed securely, but the primary issue remains the structural weakness in how the token integrity is enforced.
To mitigate this vulnerability, organizations must immediately upgrade ZITADEL to version 4.17.3 or later for the v4 branch and version 3.4.15 or later for the v3 branch, as these releases address the cryptographic implementation flaws. In environments where immediate patching is not feasible, network-level controls such as Web Application Firewalls may help detect anomalous patterns in API requests, though they cannot fully prevent token manipulation at the application layer. Developers should also review any custom integrations that handle IdP intent tokens to ensure that no legacy code paths bypass the updated security checks. Long-term remediation requires adopting authenticated encryption standards for all sensitive identity data and implementing strict validation of request parameters against session state on the server side, ensuring that token contents are verified against expected values before processing login intents or session updates.