Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.7",
  "pubDate": "2026-10-04T15:16:31.843Z",
  "pubdate": "2026-10-04T15:16:31.843Z",
  "executiveSummary": "ZITADEL versions 3.x through 3.4.15 and 4.x before 4.17.3 contain a critical vulnerability involving the use of unauthenticated, malleable encryption for Identity Provider (IdP) intent tokens.\nThis flaw allows an authenticated attacker to manipulate their own cryptographic tokens, enabling the impersonation of another user or the unauthorized hijacking of an external login intent process.\nThe vulnerability stems from the absence of integrity checks on tokens, permitting unauthorized modifications that the system subsequently accepts as valid.\nSuccessful exploitation requires the attacker to predict a victim's in-flight intent identifier and execute a timing race condition.\nThe impact includes full session hijacking and the theft of IdP tokens, posing a significant risk to the integrity of authentication flows and user account security.\nThe issue affects the /v2/idp_intents and /v2/sessions API endpoints.",
  "technicalDetails": "The vulnerability resides in the implementation of the cryptographic protection mechanism used for IdP intent tokens within ZITADEL. The system utilizes a malleable encryption scheme that lacks cryptographic integrity verification, such as an Authentication Tag provided by an AEAD (Authenticated Encryption with Associated Data) construction.\nBecause the encryption is unauthenticated, the ciphertext is susceptible to bit-flipping or other deterministic manipulation without triggering an integrity violation during the decryption process. An attacker authenticated within the ZITADEL environment can intercept their own IdP intent token and modify its underlying structure—specifically, altering the intent identifier or the associated metadata fields—to match the expected structure of a target victim's token.\nThe attack flow proceeds as follows: First, the attacker initiates an external IdP authentication process to acquire a valid, malleable intent token. Second, the attacker monitors network traffic to predict or discover an in-flight intent identifier belonging to a victim. Third, by leveraging the malleability of their own token, the attacker crafts a modified payload that corresponds to the victim's identifier. Fourth, the attacker executes a timing race condition against the ZITADEL backend, specifically targeting the /v2/idp_intents or /v2/sessions endpoints. By submitting the malformed token during the critical window where the victim's intent is pending, the attacker forces the system to bind the victim's legitimate IdP flow to the attacker's session or vice versa.\nThe absence of binding between the initial request and the finalized session allows the attacker to complete the authentication sequence under the context of the victim's identity. This bypasses typical session isolation constraints. The root cause is the reliance on encryption without MAC (Message Authentication Code) or authenticated encryption modes, which fails to ensure that the token has not been tampered with post-issuance. This flaw effectively grants an attacker the ability to inject arbitrary intent identifiers into the application state, leading to complete unauthorized access to protected resources and the potential exfiltration of sensitive IdP-derived claims."
}