Livio-A

The Login V2 UI is susceptible to host header injection. Unauthenticated attackers can poison password-reset, invite, and email-verification links by providing untrusted values in the `x-zitadel-public-host`, `x-zitadel-forward-host`, or `x-forwarded-host` headers. If an attacker knows a victim's login name, they can redirect links in legitimate emails to a host under their control to harvest single-use codes and take over accounts, including those of instance administrators.

Login V2 contains a missing authorization issue that allows attackers to approve OAuth 2.0 device authorizations using a victim's existing session without their consent. By sending a signed-in user a link containing the attacker's user code, an attacker can obtain the victim's tokens and bypass project access settings via the OIDC device authorization API.

An authentication bypass exists in the Login V2 UI that allows unauthenticated attackers to take over accounts of users who have not yet configured any authentication method. By computing a valid `verificationCheck` cookie using the user ID and browser fingerprint, an attacker can set a password, register a passkey, or link an identity provider for the target account.

A privilege escalation issue exists in the OIDC token exchange process. This flaw allows users with `IAM END USER IMPERSONATOR` or `ORG END USER IMPERSONATOR` roles to bypass the `admin.impersonation` check. Consequently, these users can impersonate administrators, including those with the `IAM OWNER` role, and sign in to relying applications with administrative roles and claims.

An authentication bypass exists in the SAML identity-provider intent callback. The system verifies the assertion signature using the provider specified in the request URL but resolves the user from the login intent without ensuring they match. This allows attackers with organization-administrator permissions to register a SAML provider using their own signing key to gain authenticated sessions as any user linked to another SAML provider on the instance, regardless of their organization.

An authentication bypass exists in the Login V2 UI. Unauthenticated attackers can obtain session tokens of other users by forging unsigned session cookies. By guessing time-ordered session IDs associated with a victim's sign-in and providing empty tokens, attackers can receive rotated tokens. This allows for full account takeover, including sessions for administrators that have already completed Multi-Factor Authentication (MFA), a security process requiring two or more verification factors.

Authenticated users can tamper with their own IdP intent tokens due to the use of unauthenticated, malleable encryption. This allows a user to modify a 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 use the '/v2/idp intents' or '/v2/sessions' endpoints to steal IdP tokens or hijack a session.

A missing authentication flaw exists in the hosted Login V1 UI. The second-factor enrollment and initialization handlers process identify-only sessions before the primary factor is verified. An attacker with knowledge of 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 by analyzing discrepant error messages.

An authentication bypass exists in Login V2 that allows unauthenticated attackers to take over accounts. Attackers who know the login name of a victim enrolled in OTP-Email and OTP-SMS can obtain One-Time Password (OTP) codes through the `returnCode` delivery type by reading them from server-action responses. This allows the attacker to establish MFA-authenticated sessions, which may include the takeover of administrator accounts.

An authentication bypass exists in the hosted Login V1 and Login V2 UIs. The system allows the enrollment of a passkey or other authenticator during identify-only login sessions before a primary factor is verified. An unauthenticated attacker who knows a victim's login name can register an attacker-controlled authenticator to gain unauthorized access to the account, bypassing passwords and multi-factor authentication (MFA).

Login V2 authentication fails to verify the inactive state of an organization, checking only the status of the individual user. This allows users belonging to a deactivated organization to sign in, create sessions, and obtain or refresh tokens if they possess valid credentials, an existing session, or a refresh token.

An issue exists where the server can be coerced into making requests to internal resources during organization domain HTTP verification. This occurs because the challenge fetch process utilizes the default `http.Get` function in Go instead of a protected client. Attackers can register domains that redirect to loopback, internal, or cloud metadata addresses, enabling them to scan ports and map internal networks. This is a server-side request forgery (SSRF), which is a flaw that allows an attacker to induce the server-side application to make requests to an unintended location.

An authentication bypass exists in the hosted Login V1 UI. The issue occurs because the registration endpoint for external accounts not found trusts external identity fields provided by the client without requiring a completed Identity Provider (IdP) callback. An unauthenticated attacker can submit forged `IDPConfigID` and `ExternalUserID` values to pre-create an account linked to a victim's external IdP identity. When the victim subsequently performs a legitimate external login, they are signed into the pre-created account.

An incorrect authorization flaw exists in the User Service API. The system verifies the `user.read` permission against the caller's organization instead of the organization that owns the target user. An authenticated member with org-scoped `user.read` permissions can use the 'GET /v2/users/{userId}/authentication methods' endpoint to identify the authentication method types registered by users in other organizations.

An issue exists where links are created between user accounts and external identity providers without verifying a primary factor or the caller's permission. This occurs during identify-only Login V2 sessions and via the User Service V2 'AddIDPLink' endpoint. An unauthenticated attacker who knows a victim's login name can bind their own external identity provider identity to the victim's account to hijack it and sign in as the victim.

ZITADEL, an open source identity management platform, had a flaw in its self-management feature. This allowed users to falsely mark their email and phone as verified without completing the verification process. The issue was addressed by enforcing proper permission checks when setting the verification flag and restricting self-management to the email address and/or phone number itself.

ZITADEL’s session management API has a flaw where an authenticated user can update a session knowing only its ID, due to a missing permission check. This enables session hijacking, allowing an attacker to impersonate another user and access sensitive resources.

Zitadel's user account deactivation mechanism did not work correctly with service accounts. Deactivated service accounts retained the ability to request tokens, which could lead to unauthorized access to applications and resources.

Zitadel is an open source identity management platform. The user grants deactivation mechanism did not work correctly, allowing deactivated user grants to be provided in tokens. This could lead to unauthorized access to applications and resources. The management and auth API always returned the state as active or did not provide any information about the state.

Zitadel is an open source identity management system. The system has a setting called "Ignoring unknown usernames" which helps mitigate attacks that try to guess or enumerate usernames. If enabled, Zitadel will show the password prompt even if the user doesn't exist and report "Username or Password invalid". However, due to an implementation change to prevent deadlocks calling the database, the flag would not be correctly respected in all cases, and an attacker would gain information if an account exists within Zitadel, since the error message shows "object not found" instead of the generic error message.