CVE-2025-64103

ZITADEL before 3.4.14 and 4.x before 4.16.2 contains an authentication bypass in the hosted Login V1 UI because the 'external account not found' registration endpoint trusts client-supplied external identity fields without a completed IdP callback. Unauthenticated attackers can submit forged IDPConfigID and ExternalUserID values to pre-create an account bound to a victim's external IdP identity, which the victim's later genuine external login then signs into.

ZITADEL 3.x before 3.4.15 and 4.x before 4.17.1 contains an improper authorization vulnerability: when issuing passkey or passwordless enrollment codes, it checks only the organization in the x-zitadel-orgid header, not the target user's organization. Attackers with user-write permission in one organization can obtain an enrollment code for a user in another organization on the same instance and register their own authenticator to take over that account.

ZITADEL 3.0.0 through 3.4.15 and 4.0.0 before 4.17.3 creates links between user accounts and external identity providers without verifying a primary factor or the caller's permission, including on identify-only Login V2 sessions and via the User Service V2 AddIDPLink endpoint. An unauthenticated attacker knowing a victim's login name can bind their own external IdP identity to the victim's account and then sign in as the victim.

ZITADEL is an open-source identity infrastructure tool. Versions 4.7.0 and below are vulnerable to an unauthenticated, full-read SSRF vulnerability. The ZITADEL Login UI (V2) treats the x-zitadel-forward-host header as a trusted fallback for all deployments, including self-hosted instances. This allows an unauthenticated attacker to force the server to make HTTP requests to arbitrary domains, such as internal addresses, and read the responses, enabling data exfiltration and bypassing network-segmentation controls. This issue is fixed in version 4.7.1.

A vulnerability in ZITADEL's federation process allowed auto-linking users from external identity providers to existing internal accounts even when the IdP was disabled or the organization disallowed federated authentication. This stemmed from the platform failing to enforce organization-specific security settings during authentication. Versions 2.71.19, 3.4.4, and 4.6.6 fix the issue by correctly validating the organization's login policy before auto-linking.

Zitadel prior to versions 4.6.0, 3.4.3, and 2.71.18 allows an attacker to perform an online brute-force attack on OTP, TOTP, and passwords. The lockout mechanism that can prevent this is not enabled by default and can cause a denial of service for the user if enabled. Additionally, mitigation strategies were not fully implemented in the more recent resource-based APIs.

ZITADEL 3.0.0 through 4.19.1 has a privilege escalation vulnerability in OIDC token exchange that allows impersonation of administrators, including IAM_OWNER, by bypassing admin impersonation checks. Attackers holding IAM_END_USER_IMPERSONATOR or ORG_END_USER_IMPERSONATOR roles can sign in to relying applications as administrators.

ZITADEL 3.0.0 before 4.19.2 contains an authentication bypass vulnerability in the Login V2 UI that allows unauthenticated attackers to obtain other users' session tokens by forging unsigned session cookies. Attackers can guess time-ordered session IDs around a victim's sign-in and supply them with empty tokens to receive rotated tokens, taking over accounts including MFA-completed administrator sessions.

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. The assertion signature is verified using the provider named in the request URL, but the user is resolved 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.

ZITADEL 3.0.0 before 4.18.0 contains a missing authentication vulnerability in the hosted Login V1 UI, where the change-username handler acts on the account bound to a login flow before any factor is verified. Unauthenticated attackers can submit a victim's login name and then post a new username to rename any active human user, including administrators, locking them out.