ZITADEL CVE-2026-56664

Exploitation requires: (1) the target ZITADEL instance must be configured with at least one external JWT Identity Provider - this is not enabled in default ZITADEL deployments; (2) the external JWT issuer must produce, or the attacker must be able to obtain, a token that omits the iat claim; (3) the attacker must possess a JWT that is validly signed by the trusted issuer (PR:L - prior credential acquisition from the issuer is required). Exploitation is limited by AC:H: the attacker cannot force an external IdP to omit iat unless they control the issuer or the issuer is misconfigured by design. Standard deployments using well-behaved OAuth2/OIDC providers that always include iat are not practically exploitable. There is no impact on confidentiality or integrity beyond what the token's own claims authorize.

The NVD-assigned CVSS 3.1 score of 4.2 (Medium) reflects a constrained attack profile: AC:H indicates that exploitation requires specific environmental conditions beyond attacker control, and PR:L confirms that some level of prior credential or token acquisition from the trusted issuer is necessary. The practical blast radius is further limited because ZITADEL must be explicitly configured with an external JWT Identity Provider - this is not a default-installation risk. No EPSS data was provided, and the vulnerability is absent from the CISA KEV catalog, suggesting no confirmed active exploitation. The C:L/I:L impact profile indicates limited, bounded damage - access is constrained to whatever the token's claims authorize rather than full platform compromise. This is a real but low-urgency issue: meaningful only to deployments actively using external JWT IdP federation with issuers that may emit iat-less tokens. The CVSS score accurately reflects real-world risk here rather than underrepresenting it.

An attacker who previously authenticated through an external JWT Identity Provider integrated with ZITADEL retains a JWT token that was issued without the iat claim - either because the external issuer does not include it or because the attacker crafted a token signed by a key they control under a trusted issuer identity. The attacker submits this token to ZITADEL's JWT IdP validation endpoint; because iat is absent, the freshness check is skipped and the token is accepted regardless of its actual age, granting the attacker continued authenticated access well past the intended session expiry.