CVE-2026-119129

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.

Starting from 2.53.6, 2.54.3, and 2.55.0, Zitadel only required multi-factor authentication if the login policy had requireMFA or requireMFAForLocalUsers enabled. If a user set up MFA without this requirement, Zitadel considered single-factor authenticated sessions valid and did not require multiple factors. Bypassing the second factor weakens MFA and enables attackers to bypass the more secure factor, e.g., targeting the TOTP code alone (six digits) without password verification. Fixed in 4.6.0, 3.4.3, and 2.71.18.

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 4.0.0 before 4.19.5 contains an authentication bypass vulnerability in the Login V2 UI that allows unauthenticated attackers to set the first credential of users lacking any authentication method. Attackers can compute a valid verificationCheck cookie from the user ID and browser fingerprint to set a password, register a passkey, or link an identity provider, taking over the account.

ZITADEL 4.0.0 before 4.19.5 contains a host header injection vulnerability in the Login V2 UI. Unauthenticated attackers can poison password-reset, invite, and email-verification links by supplying untrusted x-zitadel-public-host, x-zitadel-forward-host, or x-forwarded-host headers.

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.