ZITADEL vulnerabilities

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 3.0.0 through 3.4.15 and 4.0.0 before 4.19.5 contains a missing authorization vulnerability in Login V2 that allows attackers to approve OAuth 2.0 device authorizations using a victim's existing session without consent. Attackers can send a signed-in user a link carrying the attacker's user code to obtain the victim's tokens, and can bypass project access settings via the OIDC device authorization API.

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.

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.

Zitadel before version 4.16.2 contains a server-side request forgery (SSRF) vulnerability that allows attackers to make the server request internal resources through organization domain HTTP verification. The challenge fetch uses Go's default http.Get instead of the protected client, so attackers can register domains that redirect to loopback, internal, or cloud metadata addresses to scan ports and map internal networks.

ZITADEL 4.x before 4.17.1 does not check an organization's inactive state during Login V2 authentication, verifying only the individual user's status. Users of a deactivated organization who hold valid credentials, an existing session, or a refresh token can still sign in, create sessions, and obtain or refresh tokens.

ZITADEL 3.x before 3.4.14 and 4.x before 4.16.2 contains an authentication bypass in the hosted Login V1 and Login V2 UIs that accepts passkey or other authenticator enrollment on identify-only login sessions, before any primary factor is verified. Unauthenticated attackers knowing only a victim's login name can register an attacker-controlled authenticator and log in as that user, bypassing existing passwords and MFA.

ZITADEL before 4.17.1 contains an authentication bypass vulnerability in Login V2 that allows unauthenticated attackers to take over accounts by obtaining OTP codes via the returnCode delivery type. Attackers knowing a login name of a victim with OTP-Email and OTP-SMS enrolled can read both codes from server-action responses to gain MFA-authenticated sessions, including administrator takeover.

ZITADEL 3.x before 3.4.15 and 4.x before 4.17.1 contains a missing authentication flaw in the hosted Login V1 UI, whose second-factor enrollment and initialization handlers act on an identify-only session before any primary factor is verified. Attackers knowing only a victim's login name can enroll attacker-controlled TOTP, OTP-SMS, OTP-Email, or U2F factors, overwrite the verified phone number, and enumerate users through discrepant errors.

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.

ZITADEL 3.0.0 through 3.4.15 and 4.x before 4.17.3 contains an incorrect authorization flaw in the User Service API, which verifies user.read against the caller's organization rather than the organization owning the target user. An authenticated member holding org-scoped user.read can query GET /v2/users/{userId}/authentication_methods to learn which authentication method types users in other organizations have registered.

ZITADEL, an open source identity management platform, from 3.0.0 until 3.4.13 and 4.16.1 contains a vulnerability in Actions V1 that enables the goja Node-compatible require() registry without restricting its filesystem source loader. An organization Action author with ORG_OWNER, org.action.write, and org.flow.write permissions can run JavaScript at OIDC, SAML, and login-flow trigger points and load files readable by the ZITADEL server process. This can disclose mounted configuration and secrets, including credentials stored through ZITADEL_FIRSTINSTANCE_LOGINCLIENTPATPATH or ZITADEL_FIRSTINSTANCE_MACHINEKEYPATH, and recovered bootstrap credentials can enable escalation from an organization administrator to an instance administrator. This issue is fixed in versions 3.4.13 and 4.16.1.

ZITADEL, an open source identity management platform, from 4.0.0 until 4.16.1 contains a vulnerability in Login V2 that creates a browser session after password verification and can reuse that session for a later authentication request without verifying a user's enrolled TOTP, OTP, or U2F second factor. When the MFA step is abandoned and login starts again, session-validity checks require MFA only when the organization enables Force MFA or Force MFA for local users only, so a voluntarily enrolled factor can be skipped while completing an OIDC or SAML callback for a customer application. Login V1, the ZITADEL Console, Management and Admin APIs, and user self-management are not affected. This issue is fixed in version 4.16.1.

ZITADEL is an open source identity management platform. Prior to version 4.16.0, a bug in how ZITADEL updates permissions when multiple project roles are deleted at the same time can cause some user permissions to be missed. This issue specifically affects User Grants on Granted Projects (projects shared between different organizations), potentially allowing users to keep access rights that were supposed to be completely removed.

In ZITADEL from 2.43.0 through 2.71.19, 3.0.0 through 3.4.11, and 4.0.0 through 4.15.1, the email and phone self-management APIs allowed users to request returned verification codes without required permissions. This allows claiming ownership of other users' email addresses or phone numbers and bypassing email/phone-based security policies.

A vulnerability in ZITADEL prior to version 4.15.3 allows a low-privilege token to be exchanged for elevated permissions in another application. This occurs because the OAuth2 Token Exchange endpoint does not verify that the subject token belongs to the requesting client or that requested scopes remain within the original token's scopes.

In ZITADEL prior to version 4.15.3, the Login V2 OIDC and SAML FailedPrecondition error paths pass loginSettings.defaultRedirectUri to router.push without applying the isSafeRedirectUri check. This allows an organization or instance administrator to store a javascript or data URI that can execute in a user's browser when an affected login error path is reached.

In ZITADEL prior to version 4.15.3, the external identity provider handler checks that the local user's email is verified but does not verify that the external IdP confirmed ownership of the same email before auto-linking by email. This allows a permissive provider account with a victim email address to be linked to the victim's local account.

A vulnerability in ZITADEL (versions 3.0.0-rc.1 through 3.4.11 and 4.0.0-rc.1 through 4.15.1) causes external JWT validation to skip expiration handling when the token lacks the exp claim. A token from a trusted issuer is treated as valid without an automatic expiration window.

In ZITADEL prior to versions 3.4.12 and 4.15.2, the external JWT Identity Provider validation skips the maximum token age freshness check when an incoming token omits the iat claim, allowing arbitrarily old tokens from a trusted issuer to pass authentication.

In ZITADEL prior to versions 3.4.12 and 4.15.2, OAuth2 and OIDC flows (CodeExchange, RefreshToken, device token) fail to verify that the requesting client matches the client that initiated the authorization flow, allowing intercepted grants or refresh tokens to be exchanged under a different client.

A vulnerability in ZITADEL from version 4.0.0-rc.1 to 4.15.1 allows SSRF attacks due to inconsistent URL validation in HTTP notification channels, OIDC BackChannel logout, and SAML metadata URL fetches. Attackers can use DNS rebinding, redirects, or protocol downgrades to send requests to loopback, internal IP, or link-local endpoints.

In ZITADEL prior to version 4.15.1, the event store validation can retain the original resource owner for a deleted user identifier, causing a later user recreated with the same identifier in another organization to be provisioned under the original organization and exposed to that organization's administrator. This issue is fixed in version 4.15.2.

ZITADEL, an open source identity management platform, prior to versions 3.4.12 and 4.15.2 does not validate the audience (aud) claim in its external JWT Identity Provider. This allows a validly signed token from a trusted issuer intended for another relying party to be accepted by ZITADEL.

ZITADEL, an open-source identity infrastructure tool, versions 2.44.0 through 3.4.4 and 4.0.0-rc.1 through 4.7.1 disclose the total number of instance users to authenticated users, regardless of their specific permissions. While this does not leak individual user data or PII, disclosing the total user count via the totalResult field constitutes an information disclosure vulnerability that may be sensitive in certain contexts.

ZITADEL versions 4.0.0-rc.1 through 4.7.0 are vulnerable to DOM-Based XSS through the Zitadel V2 logout endpoint. The /logout endpoint insecurely routes to a value supplied in the post_logout_redirect GET parameter, allowing an unauthenticated remote attacker to execute malicious JavaScript in Zitadel users' browsers. The attack requires multiple active user sessions in the same browser, and account takeover is mitigated when using Multi-Factor Authentication (MFA) or Passwordless authentication. This issue is fixed in version 4.7.1.

ZITADEL, an identity infrastructure software, prior to versions 4.6.0, 3.4.3, and 2.71.18 contains a vulnerability in the password reset mechanism. ZITADEL uses the Forwarded or X-Forwarded-Host header from incoming requests to construct the URL for the password reset confirmation link, which is then emailed to the user. If an attacker can manipulate these headers (e.g., via host header injection), they could cause ZITADEL to generate a password reset link pointing to a malicious domain and capture the reset code, then use it to reset the user's password and gain unauthorized access. The vector is mitigated for accounts with MFA or Passwordless authentication enabled.