CVE-2026-56665: Logical Validation Bypass in ZITADEL External JWT Identity Provider

ZITADEL is an open-source identity management platform designed to orchestrate user authentication, authorization, and federation. To support federated identities, ZITADEL allows administrators to configure external Identity Providers (IdPs) that authenticate users via JSON Web Tokens (JWTs). This vulnerability, designated as CVE-2026-56665, resides within the backend logic responsible for validating these external assertions.

The specific affected component is the external JWT Identity Provider validation engine located in internal/idp/providers/jwt/session.go. This module verifies incoming cryptographic signatures and temporal claims of incoming JWTs to establish authenticated user sessions. The attack surface is exposed to any network actor capable of interacting with authentication flows governed by external JWT-based identity federation.

At its core, the vulnerability represents an instance of CWE-613: Insufficient Session Expiration. Due to a logical implementation error in evaluating temporal claims, ZITADEL failed to unconditionally enforce token lifetime restrictions. This allowed specially structured tokens to remain valid indefinitely, posing a threat to session integrity and federation boundaries.

In Go applications, JSON parsing libraries unmarshal missing numeric or string fields into their respective zero values. For timestamps represented by the time.Time struct, a missing JSON field defaults to the zero-value timestamp, which is January 1, year 1, 00:00:00 UTC. The underlying OpenID Connect (OIDC) library behaves similarly when temporal claims such as Expiration (exp) and Issued At (iat) are absent from a token.

Within ZITADEL's validateToken function, the validation checks for exp and iat were guarded by conditions evaluating whether the claims were non-zero. The implementation checked if !claims.GetExpiration().IsZero() and !claims.GetIssuedAt().IsZero() were true before calling the validation library. This logic assumes that a zero-value claim simply means the claim was not supplied and therefore cannot be evaluated.

However, this assumption introduces a severe validation bypass. If a trusted external Identity Provider issues a JWT without an exp claim, the claim unmarshals to the zero timestamp. The conditional statement evaluates to false, causing the engine to skip the oidc.CheckExpiration function entirely. Consequently, the application treats the token as valid because no expiration check is executed.

The vulnerable implementation in ZITADEL's session.go exposed a critical structural logic flow. Below is the vulnerable code segment that illustrates how the validation checks were conditionally bypassed:

// Vulnerable Code Path
if !claims.GetExpiration().IsZero() {
	if err = oidc.CheckExpiration(claims, offset); err != nil {
		return nil, fmt.Errorf("%w: expired: %v", ErrInvalidToken, err)
	}
}
 
if !claims.GetIssuedAt().IsZero() {
	if err = oidc.CheckIssuedAt(claims, maxAge, offset); err != nil {
		return nil, fmt.Errorf("%w: %v", ErrInvalidToken, err)
	}
}

The patch resolved this logical flaw by removing the conditional wrappers entirely. By making calls to oidc.CheckExpiration and oidc.CheckIssuedAt unconditional, the OIDC library is forced to process all incoming claims regardless of whether they contain zero values. The library's internal logic will then correctly reject tokens that lack required temporal attributes. Below is the patched implementation:

@@ -92,17 +92,14 @@ func (s *Session) validateToken(ctx context.Context, token string) (*oidc.IDToke
 		return nil, fmt.Errorf("%w: invalid signature: %v", ErrInvalidToken, err)
 	}
 
-	if !claims.GetExpiration().IsZero() {
-		if err = oidc.CheckExpiration(claims, offset); err != nil {
-			return nil, fmt.Errorf("%w: expired: %v", ErrInvalidToken, err)
-		}
+	if err = oidc.CheckExpiration(claims, offset); err != nil {
+		return nil, fmt.Errorf("%w: expired: %v", ErrInvalidToken, err)
 	}
 
-	if !claims.GetIssuedAt().IsZero() {
-		if err = oidc.CheckIssuedAt(claims, maxAge, offset); err != nil {
-			return nil, fmt.Errorf("%w: %v", ErrInvalidToken, err)
-		}
+	if err = oidc.CheckIssuedAt(claims, maxAge, offset); err != nil {
+		return nil, fmt.Errorf("%w: %v", ErrInvalidToken, err)
 	}
+
 	return claims, nil
 }

The following diagram maps the execution flow of the validation logic before and after the patch:

To successfully exploit this vulnerability, an attacker must acquire or generate a cryptographically valid JWT from an external Identity Provider trusted by the target ZITADEL instance. The attacker must target a configuration where the external IdP or the trusted signing source does not strictly require or enforce the presence of temporal claims during token creation. This scenario is common in misconfigured private key infrastructures or developmental identity setups.

The exploitation process begins with the attacker constructing or obtaining a JWT signed by the trusted issuer's private key. Crucially, this token is formatted to exclude the exp (expiration) and iat (issued at) claims, while retaining mandatory structural elements such as the subject and signature. The attacker then initiates the authentication flow with the ZITADEL instance, supplying this custom token as the assertion.

Upon receiving the token, ZITADEL verifies the cryptographic signature against the cached JSON Web Key Set (JWKS) retrieved from the trusted provider. Because the signature is valid, the cryptographic integrity check succeeds. The logic then proceeds to the parsed claims validation. Because the temporal checks are bypassed due to the zero-value evaluation, ZITADEL establishes an authorized session. This session has no defined lifetime bounds, allowing the attacker to reuse the token or maintain persistence indefinitely.

The impact of CVE-2026-56665 is primarily associated with session persistence and security boundary evasion. An attacker possessing an expired or indefinitely valid token can bypass regular authentication lifecycles to maintain unauthorized access. This compromises the Principle of Least Privilege and undermines the session management controls expected in enterprise identity federations.

While the CVSS base score of 4.2 indicates a medium-severity issue, the actual risk is heavily dependent on the deployment architecture. If the ZITADEL instance relies on external JWT providers that lack strict claim-enforcement policies, the severity escalates. The attack complexity is rated high because the attacker must have a mechanism to obtain or sign trusted tokens that lack standard temporal claims.

This vulnerability has not been observed in active ransomware campaigns or general wild exploitation, according to EPSS and CISA KEV catalogs. However, the logical nature of the bypass makes it highly reliable once the initial requirements are satisfied. The compromised state allows read and write capabilities associated with the identity mapped from the external provider.

The primary remediation path is the immediate upgrade of ZITADEL to the patched versions. Administrators should deploy version 3.4.12 or higher for the v3.x release train, and version 4.15.2 or higher for the v4.x release train. These updates replace the conditional temporal checks with mandatory enforcement, causing any token lacking expiration claims to be systematically rejected.

If upgrading immediately is not feasible, administrators must implement mitigation strategies at the identity provider level. External Identity Providers trusted by ZITADEL should be hardened to enforce the absolute inclusion of exp and iat claims on all issued JWTs. Additionally, any custom token-signing services must be audited to ensure they cannot output claims-deficient tokens.

Network administrators can also employ intermediate web application firewalls or API gateways to perform schema validation. Inbound traffic destined for the federated login endpoints can be analyzed to ensure that all incoming JWT assertions contain valid, non-empty temporal elements. This provides a secondary layer of defense while preparation for the software update is finalized.