ZITADEL Login V2 approves OAuth 2.0 device authorizations with the browser's existing signed-in session, without asking for consent or requiring the user code shown on the device. An attacker who starts a device authorization and gets a signed-in user to open one link can receive that user's tokens, including API access with the ZITADEL project scope. The same missing check allows bypassing project access settings through the OIDC device authorization API.
ZITADEL · ZITADEL
ZITADEL's hosted Login V2 UI trusts a verificationCheck cookie that is derived only from the user ID and the browser fingerprint, so it can be computed by anyone. An unauthenticated attacker who knows the user ID or login name of an active user without any authentication method can set that user's first password, register a passkey, or link an external identity provider, and then sign in as that user. Users who already have a password, passkey or identity provider link are not affected, and the ZITADEL APIs are not affected.
ZITADEL · ZITADEL
ZITADEL versions 4.0.0 up to 4.19.4 accept untrusted public host headers in the Login V2 UI. An unauthenticated attacker who knows a victim's login name can make genuine password-reset, invite and email-verification emails contain links to the attacker's host. When the victim opens the link, or automated mail scanning fetches it, the attacker captures the single-use code and can take over the account, including instance administrators. User interaction is required, and the default Login V2 deployment is affected.
ZITADEL · ZITADEL
ZITADEL 4.0.0 through 4.19.1 and 3.0.0 through 3.4.15 contain a flaw in the Login V2 hosted login UI: the session cookie is neither signed nor validated. An unauthenticated attacker who can reach the login UI and guess a victim's time-ordered session ID can obtain a fresh token for the victim's authenticated session, including sessions where MFA was completed. This can lead to full takeover of an instance administrator account, and the attack depends on timing and on the session ID being guessable.
ZITADEL · ZITADEL
ZITADEL has an authentication bypass in the SAML identity provider intent callback used by Login V2 and custom login UIs. An attacker who holds organization-administrator permission can register a SAML identity provider with a signing key they control and obtain an authenticated session as any user linked to a different SAML provider on the same instance, including users in other organizations. The issue requires an instance with at least two SAML identity providers and does not by itself grant administrative rights.
ZITADEL · ZITADEL
The hosted Login V1 UI of ZITADEL changes a username before the login flow has verified any authentication factor. An unauthenticated attacker who knows a victim's login name can rename any active human user, including instance administrators, which locks the legitimate owner out. The attacker cannot take over the account, because no password, session or token is disclosed.
ZITADEL · ZITADEL
ZITADEL's hosted Login V1 UI trusts client-supplied external identity fields in the 'external account not found' registration endpoint. An unauthenticated attacker can pre-create an account bound to a victim's external IdP identity, and the victim's later genuine external login signs into that attacker-prepared account. Exploitation requires that Login V1 is in use and that at least one external IdP allows manual account creation. Login V2 is not affected.
ZITADEL · ZITADEL
ZITADEL 4.x before 4.17.1 checks only the individual user's status during Login V2 authentication and ignores whether the user's organization has been deactivated. Users of a deactivated organization who still hold valid credentials, an existing session or a refresh token can sign in, create sessions and obtain or refresh tokens. Login V1 is not affected, and sessions and tokens issued before deactivation may remain usable until they expire.
ZITADEL · ZITADEL
ZITADEL's hosted Login V1 and Login V2 UIs accept passkey or other authenticator enrollment on identify-only login sessions, before a primary factor is verified. An unauthenticated attacker who knows only a victim's login name can register an attacker-controlled authenticator and log in as that user, bypassing passwords and MFA. Applications that authenticate users through the affected hosted login UIs are exposed.
ZITADEL · ZITADEL
ZITADEL's hosted Login V2 UI can be abused by an unauthenticated attacker who knows only a victim's login name. If the victim has both OTP-Email and OTP-SMS enrolled, the attacker can read both one-time codes from server-action responses and obtain a fully MFA-authenticated session. This can lead to full instance takeover if the victim is an instance administrator.
ZITADEL · ZITADEL
ZITADEL's hosted Login V1 UI accepts second-factor enrollment and initialization requests before the primary factor is verified. An attacker who knows only a victim's login name can register attacker-controlled TOTP, OTP-SMS, OTP-Email or U2F factors, overwrite the verified phone number and enumerate valid users through differing error messages. The flaw does not by itself allow account takeover, because the password is still required to log in. Applications that authenticate users through Login V1 are affected; Login V2 is not.
ZITADEL · ZITADEL
ZITADEL 3.x before 3.4.15 and 4.x before 4.17.1 does not check the organization of the target user when issuing passkey or passwordless enrollment codes. It only checks the organization named in the x-zitadel-orgid header. An attacker with user-write permission in one organization can obtain an enrollment code for a user in another organization on the same instance, register their own authenticator and take over that account. The flaw matters only on instances hosting several organizations and requires an authenticated account with user-write permission. The CVE record scores it 9.3 (CVSS v4.0); the GitHub advisory scores it 9.6 (CVSS v3.1).
ZITADEL · ZITADEL
ZITADEL, an open-source identity provider, protects IdP intent tokens used for external identity provider logins with encryption that has no integrity check. An authenticated user with a valid account on the same instance can modify their own token so the backend accepts it for another user's pending external login. If the attacker also predicts the victim's intent identifier and wins a timing race, they can read the victim's external IdP tokens or hijack the victim's session. The attack is probabilistic and time-limited, and instances that do not use external identity providers are not affected.
ZITADEL · ZITADEL
ZITADEL versions 3.0.0 through 3.4.15 and 4.0.0 through 4.17.2 create links between user accounts and external identity providers (IdPs) without verifying a primary factor or the caller's permission. An unauthenticated attacker who knows a victim's login name can bind their own external IdP identity to the victim's account through the Login V2 UI and then sign in as the victim. Any authenticated user can also pre-claim external identities via the User Service V2 AddIDPLink API. The Login V2 path requires an organisation that permits external IdP account linking.
ZITADEL · ZITADEL
