Summary

A vulnerability in ZITADEL’s Login V2 UI allowed a password-verified browser session to be reused for a new authentication request without re-checking a user’s enrolled second factor (TOTP, OTP, or U2F). An attacker who already knows valid credentials can fully authenticate to an application without completing MFA.

Impact

ZITADEL Login V2 issues a session as soon as the user’s password is verified, before the MFA challenge is completed. If the MFA step is abandoned (for example by navigating back) and login is started again, Login V2 may reuse that existing session instead of requiring the second factor.

Session validity checks only enforced MFA verification when the organization’s login policy had Force MFA (or Force MFA for local users only) enabled. They did not treat a voluntarily enrolled second factor as required. In the common case where MFA is available on the user but not organization-mandated, a password-only session was treated as fully authenticated and used to complete the OIDC or SAML callback, bypassing the user’s second factor.

Scope note: This issue affects customer applications that authenticate users through the hosted Login V2 UI (OIDC/SAML). It does not affect Login V1. It also does not affect authentication to ZITADEL itself — including the Console, the Management/Admin APIs, and user self-management — even when Login V2 is enabled.

Affected Versions

Systems running one of the following versions are affected:

4.x: 4.0.0 through 4.16.0 (including RC versions)

Patches

The vulnerability has been addressed in the latest releases. The patch ensures Login V2 validates that any second factor enrolled on the user has been verified before an existing session can be reused to complete authentication.

4.x: Upgrade to $\ge$ 4.16.1

Workarounds

If an immediate upgrade is not possible, enable Force MFA (or Force MFA for local users only, if you want to exempt IdP/federated logins) in the affected organization’s — or the instance default — login policy. This makes second-factor verification mandatory for password logins and closes this session-reuse bypass.

Note that this is a broader policy change (MFA becomes mandatory for the scoped local logins) rather than a narrow fix limited to users who already self-enrolled a second factor.

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

Thanks to Philippe Wechsler (@MadMonkey87) for finding and reporting the vulnerability.

Summary

A vulnerability in ZITADEL Actions V1 allows an organization Action author to read files from the ZITADEL host filesystem through the JavaScript require() module loader. On common self-hosted deployments this can be chained to steal bootstrap credentials (including the Login Client PAT) and escalate from a single-tenant organization owner to instance administrator.

Impact

ZITADEL Actions V1 run custom JavaScript inside the ZITADEL server process at OIDC, SAML, and login-flow trigger points. The runtime enables the goja Node-compatible require() registry without restricting the source loader, so Action scripts can load host files readable by the ZITADEL process (notably .js and .json, and in some cases other file contents via error channels).

An attacker with ORGOWNER on any organization (which includes org.action.write and org.flow.write) can therefore:

Read process-readable host files, including configuration or secrets mounted into the API container (for example service-account material, projected secrets, or config carrying sensitive values). On deployments that follow ZITADEL’s documented bootstrap paths (ZITADELFIRSTINSTANCELOGINCLIENTPATPATH, ZITADELFIRSTINSTANCEMACHINEKEYPATH), recover instance-wide credentials such as the IAMLOGINCLIENT PAT or the IAMOWNER service-account key, enabling escalation to full instance control.

This collapses the expected multi-tenant isolation boundary: a tenant organization administrator is not meant to access host filesystem secrets or instance-wide credentials.

Scope note: This issue affects Actions V1. Host command execution was not identified as part of this vulnerability. Impact depends on what the ZITADEL process can read on disk and on deployment layout — documented Compose and quick-start setups that write bootstrap PATs or machine keys into the API container amplify severity.

Affected Versions

Systems running one of the following versions are affected:

4.x: 4.0.0 through 4.16.0 (including RC versions) 3.x: 3.0.0 through 3.4.12 (including RC versions)

Patches

The vulnerability has been addressed in the latest releases. The patch disables filesystem-backed module loading for Action scripts so that only the intended native zitadel/ modules can be required.

4.x: Upgrade to $\ge$ 4.16.1 3.x: Upgrade to $\ge$ 3.4.13

Workarounds

If an immediate upgrade is not possible:

Restrict who can create, update, or attach Actions — do not grant org.action.write / org.flow.write (or ORGOWNER) to untrusted administrators in multi-tenant environments. Audit existing Actions for require() of filesystem paths. Remove or relocate bootstrap credential files (login-client.pat, machine keys) so they are not readable inside the API process filesystem. Limit host filesystem exposure for the ZITADEL process (no unnecessary readable secrets beside the binary).

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

Thanks to Dor Konis (@dkonis) and Feras Daragma (@FerasTr) from GE Vernova, and to pyuysig, for finding and reporting this vulnerability.

Summary

A vulnerability in Zitadel's self-management capability allowed users to mark their email and phone as verified without going through an actual verification process.

While GHSA-282g-fhmx-xf54 (CVE-2026-27946, "Users Can Self-Verify Email/Phone via UpdateHumanUser API") closed the path that let any authenticated user mark an arbitrary email or phone as verified on their own account by calling UpdateHumanUser with email.isverified: true, additional paths were discovered.

Impact

Zitadel provides an API for managing users. The API also allows users to self-manage their own data including updating the email and phone.

Due to an improper permission check, the API allowed returning the verification code for the email and phone to the own user. This allows users to claim ownership of an email or phone they do not control and potentially bypass email-based security policies.

Note that when changing another user's email or phone, regardless of the verification flag, the permissions were correctly checked.

Affected Versions

Systems running one of the following versions are affected: - 4.x: 4.0.0 through 4.15.0 (including RC versions) - 3.x: 3.0.0 through 3.4.10 (including RC versions) - 2.x: 2.43.0 through 2.71.19

Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring the correct permission in case the verification flag is provided and only allows self-management of the email address, resp. phone number itself.

4.x: Upgrade to >=4.15.1 3.x: Update to >=3.4.11 2.x: Update to >=3.4.11

Workarounds

The recommended solution is to upgrade to a patched version. If an upgrade is not possible, an action (v2) could be used to prevent returning the verification code to the own user.

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

Thanks to eddieran for reporting this vulnerability.

Summary

A flaw in the external identity provider handler allows unauthorized account linking to occur under specific administrative configurations. When auto-linking by email is enabled, ZITADEL checks that the local user's email is verified, but does not explicitly cross-check whether the incoming external identity provider (IdP) also verified that email address upstream.

Impact

When a user logs in via an external identity provider, the system can automatically link them to an existing local account if their email addresses match. However, because the system fails to check if the external provider actually verified ownership of that email, a security risk is introduced if a loose or public provider is connected.

If an administrator enables email auto-linking for an external identity provider that allows anyone to sign up with an unverified email address, an attacker can exploit this behavior. By registering an account on that permissive provider using a victim's email address and logging in, the system will automatically link the attacker's federated identity to the victim's legitimate local account. This allows the attacker to log into the victim's account without requiring any interaction or confirmation from the victim.

This issue represents a configuration-dependent anomaly rather than an unconditioned attack vector. Because the scenario relies entirely on an explicit administrative choice to trust a permissive external directory and link accounts automatically based purely on email strings, the practical operational risk is classified as Medium.

Affected Versions

Systems running one of the following versions are affected:

4.x: 4.0.0 through 4.15.2 (including RC versions) 3.x: 3.0.0 through 3.4.12 (including RC versions)

Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring that the external identity provider's email verification status is explicitly validated before allowing any automatic linking logic to proceed.

4.x: Upgrade to $\ge$ 4.15.3 3.x: Upgrade to $\ge$ 4.15.3

Workarounds

If an immediate upgrade is not possible, implement one of the following mitigations:

Disable auto-linking by email entirely by setting the option to AUTOLINKINGOPTIONUNSPECIFIED on corresponding identity providers. Audit external IdP configurations and restrict email auto-linking strictly to trusted enterprise identity directories (e.g., corporate Okta or Azure AD) where email verification is strictly enforced and managed by corporate policy.

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

Thanks to Android-Login-Analysis and Alejandro Yadlin for reporting this vulnerability.

ZITADEL is an open source identity management platform. Prior to 4.15.3, ZITADEL Login V2 OIDC and SAML FailedPrecondition error paths return loginSettings.defaultRedirectUri to router.push without applying the isSafeRedirectUri check, allowing 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. This issue is fixed in version 4.15.3.

Summary

A token lifecycle validation vulnerability was discovered in ZITADEL's external JWT Identity Provider (IdP) implementation Specifically, within the validation pipeline, if an incoming JWT omits the exp claim entirely, the expiration block is silently skipped rather than rejected. The token is treated as valid forever.

Per the OIDC Core 1.0 specification, identity token validation pipelines must strictly handle and enforce session expiration. ZITADEL's silent acceptance of tokens missing these temporal constraints compromises session integrity.

Impact

An attacker in possession of a token lacking an exp claim holds a permanent credential with no automatic expiration or revocation window.

Affected Versions

Systems running one of the following versions are affected:

4.x: 4.0.0 through 4.15.1 (including RC versions) 3.x: 3.0.0 through 3.4.11 (including RC versions)

Patches

The vulnerability has been addressed in the latest releases. ZITADEL now explicitly rejects tokens that lack an exp claim.

4.x: Upgrade to $\ge$ 4.15.2 3.x: Upgrade to $\ge$ 3.4.12

Workarounds

The recommended solution is to update ZITADEL to a patched version.

If an immediate upgrade is not feasible, ensure at the upstream Identity Provider level that an external IdP explicitly includes the exp claim in all signed JWTs.

Publication Note

This issue was originally disclosed as part of a unified security bulletin published under GHSA-wxg7-w2v3-w38g. To satisfy CVE Numbering Authority regulations regarding independently fixable logic flaws, the missing token expiration validation (exp) has been moved into this separate tracking entry so a distinct CVE ID can be correctly mapped to it.

Questions

If there are any questions or comments about this advisory, send an email to security@zitadel.com

Credits

ZITADEL thanks Android-Login-Analysis, Jason Zhou and Pedro Giglioti for reporting this vulnerability.

Summary

A vulnerability was discovered in Zitadel's LDAP identity provider implementation, which fails to properly escape user-provided usernames before incorporating them into LDAP search filters. This allows unauthenticated attackers to perform LDAP Filter Injection during the login process.

Impact

While this vulnerability does not allow for a full authentication bypass, an attacker can use LDAP metacharacters (such as , (, )) to perform blind LDAP injection. By observing the different failure (or success) responses, an attacker can systematically enumerate valid usernames and extract sensitive attribute data from the connected LDAP directory.

Note that an authentication bypass is not possible.

Affected Versions

Systems integrating LDAP as IdPs and running one of the following versions are affected:

- 4.x: 4.0.0 through 4.14.0 (including RC versions) - 3.x: 3.1.0 through 3.4.9 - 2.x: 2.71.11 through 2.71.19

Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring the correct permission in case the verification flag is provided and only allows self-management of the email address, resp. phone number itself.

- 4.x: Upgrade to >=4.15.0 - 3.x: Update to >=3.4.10 - 2.x: Update to >=3.4.10

Workarounds

The recommended solution is to upgrade to a patched version. If an immediate upgrade is not possible, developers should ensure their project's LDAP directory has strict access controls to limit the scope of information disclosure.

Questions

If there are any questions or comments about this advisory, please send an email to security@zitadel.com

Credits

This vulnerability was identified and reported by ProScan AppSec (https://proscan.one/).

Summary

A vulnerability in Zitadel's OAuth2/OIDC interface, which allowed users to bypass organization enforcement during authentication.

Impact

Zitadel allows applications to enforce an organzation context during authentication using scopes (urn:zitadel:iam:org:id:{id} and urn:zitadel:iam:org:domain:primary:{domainname}). If enforced, a user needs to be part of the required organization to sign in.

While this was properly enforced for OAuth2/OIDC authorization requests in login V1, corresponding controls were missing for device authorization requests and all login V2 and OIDC API V2 endpoints. This allowed users to bypass the restriction and sign in with users from other organizations.

Note that this enforcement allows for an additional check during authentication and applications relying on authorizations / roles assignments are not affected by this bypass.

Affected Versions

Systems running one of the following versions are affected: - 4.x: 4.0.0 through 4.12.2 (including RC versions) - 3.x: 3.0.0 through 3.4.8 (including RC versions)

Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by validating the provided scopes and enforcing the organization existence when processing the authorization request. Additionally it will prevent the use of a session of a user which does not belong to the required organization on the OIDC service endpoints (CreateCallback and Authorize or Deny Device Authorization endpoints).

4.x: Upgrade to >=4.12.3 3.x: Update to >=3.4.9

Workarounds

The recommended solution is to upgrade to a patched version.

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

Thanks to @motoki317 for reporting this vulnerability.

ZITADEL is an open source identity management platform. Prior to 3.4.8 and 4.12.2, a potential vulnerability exists in Zitadel's passkey registration endpoints. This endpoint allows registering a new passkey using a previously retrieved code. An improper expiration check of the code, could allow an attacker to potentially register their own passkey and gain access to the victim's account. This vulnerability is fixed in 3.4.8 and 4.12.2.

ZITADEL is an open source identity management platform. Prior to 3.4.8 and 4.12.2, a vulnerability in Zitadel's Management API has been reported, which allowed authenticated users holding a valid low-privilege token (e.g., project.read, project.grant.read, or project.app.read) to retrieve management-plane information belonging to other organizations by specifying a different tenant’s projectid, grantid, or appid. This vulnerability is fixed in 3.4.8 and 4.12.2.

ZITADEL is an open source identity management platform. From 2.68.0 to before 3.4.8 and 4.12.2, Zitadel provides a System for Cross-domain Identity Management (SCIM) API to provision users from external providers into Zitadel. Request to the API with URL-encoded path values were correctly routed but would bypass necessary authentication and permission checks. This allowed unauthenticated attackers to retrieve sensitive information such as names, email addresses, phone numbers, addresses, external IDs, and roles. Note that due to additional checks when manipulating data, an attacker could not modify or delete any user data. This vulnerability is fixed in 3.4.8 and 4.12.2.

ZITADEL is an open source identity management platform. From version 4.0.0-rc.1 to 4.7.0, a potential vulnerability exists in ZITADEL's password reset mechanism in login V2. ZITADEL utilizes the Forwarded or X-Forwarded-Host header from incoming requests to construct the URL for the password reset confirmation link. This link, containing a secret code, is then emailed to the user. This issue has been patched in version 4.7.1.

Summary

A vulnerability in Zitadel's login V2 interface was discovered, allowing for possible account takeover.

Impact

Zitadel allows organization administrators to change the default redirect URI for their organization. This setting enables them to redirect users to an arbitrary location after they log in.

Due to missing restrictions and improper handling, malicious javascrtipt code could be executed in Zitadel login UI (v2) using the users’ browser.

An unauthenticated remote attacker can exploit this Stored XSS vulnerability, reset the password of their victims, and take over their accounts.

It's important to note that this specific attack vector is mitigated for accounts that have Multi-Factor Authentication (MFA) or Passwordless authentication enabled.Stored XSS vulnerability.

Affected Versions

Systems running one of the following versions are affected: - 4.x: 4.0.0 through 4.11.1 (including RC versions)

Patches

The vulnerability has been addressed in the latest releases. The login UI prevents execution of such code. Additionally, the page to change the password, now always requires the user's current password regardless of the state of the authenticated session.

4.x: Upgrade to >= 4.12.0

Workarounds

The recommended solution is to upgrade to a patched version.

Questions

If there are any questions or comments about this advisory, please send an email to security@zitadel.com

Credits

ZITADEL extends thanks once again to Amit Laish from GE Vernova for finding and reporting the vulnerability.

Summary

A vulnerability in Zitadel's login V2 UI allowed users to bypass login behavior and security policies and self-register new accounts or sign in using password even if corresponding options were disabled in their organizaton.

Impact

Zitadel enables administrators to configure their organization’s login behavior and security policies. As part of this functionality, they can disable user self-registration, enforce passwordless logins only, and more.

Due to improper enforcement an attacker could send direct HTTP requests to the login UI and create accounts in organizations that have disabled user self-registration, and gain unauthorized access to the system. The same attack vector could be used to authenticate for example using username and password even when this login method was disabled.

Affected Versions

Systems running one of the following versions are affected: - 4.x: 4.0.0 through 4.12.0 (including RC versions)

Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by enforcing the policies on the logiin UI server.

4.x: Upgrade to >=4.12.1

Workarounds

The recommended solution is to upgrade to a patched version.

Questions

If there are any questions or comments about this advisory, please send an email to security@zitadel.com

Credits

ZITADEL extends thanks once again to Amit Laish from GE Vernova for finding and reporting the vulnerability.

Summary

A vulnerability was discovered in Zitadel's login V2 interface that allowed a possible account takeover.

Impact

Zitadel exposes an HTTP endpoint named /saml-post. This endpoint is used for handling requests to SAML IdPs and accepts two HTTP GET parameters: url and id. When these parameters are supplied, users’ browsers auto-submit an HTTP POST request to the provided url parameter. The endpoint insecurely redirects users using the provided url GET parameter. As a result, by specifying a javascript: scheme, malicious JS code could be executed on Zitadel users’ browsers.

The endpoint also reflects user-supplied input in the server response, without HTML-encoding it. As a result, it is possible to inject arbitrary HTML code, which again leads to malicious JS code execution in the Zitadel users’ browsers.

An unauthenticated remote attacker can exploit these XSS vulnerabilities, and thus, execute malicious JavaScript code on behalf of Zitadel users. By doing so, such an attacker could reset the password of their victims, and take over their accounts.

It's important to note that this specific attack vector is mitigated for accounts that have Multi-Factor Authentication (MFA) or Passwordless authentication enabled.

Affected Versions

Systems running one of the following versions are affected: - 4.x: 4.0.0 through 4.11.1 (including RC versions) Important Note: Although this /saml-post endpoint is used when Zitadel is integrated with a SAML Identity Provider (IdP), the vulnerability in this finding does not require Zitadel to be configured with a SAML IdP. Consequently, Zitadel is vulnerable in its default, out-of-the-box configuration.

Patches

The vulnerability has been addressed in the latest releases. The patch reworked the integration of SAML IdPs and the /saml-post endpoint no longer exists. Additionally, the page to change the password, now always requires the user's current password regardless of the state of the authenticated session.

4.x: Upgrade to >= 4.12.0

Workarounds

The recommended solution is to upgrade to a patched version. If an upgrade is not possible and no SAML IdP integration is needed, a WAF or reverse proxy rule can be deployed to prevent access to the endpoint.

Questions

If there are any questions or comments about this advisory, please email them to security@zitadel.com

Credits

ZITADEL extends thanks once again to Amit Laish from GE Vernova for finding and reporting the vulnerability.

Summary

A vulnerability in ZITADEL's self-management capability allowed users to mark their email and phone as verified without going through an actual verification process.

Impact

ZITADEL provides an API for managing users. The API also allows users to self-manage their own data including updating the email and phone.

Due to an improper permission check, the API allowed setting the verified flag for the email and phone on the own user. This allows users to claim ownership of an email or phone they do not control and potentially bypass email-based security policies.

Note that when changing another user's email or phone, regardless of the verification flag, the permissions were correctly checked.

Affected Versions

Systems running one of the following versions are affected: - 4.x: 4.0.0 through 4.11.0 (including RC versions) - 3.x: 3.0.0 through 3.4.6 (including RC versions) - 2.x: 2.43.0 through 2.71.19

Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring the correct permission in case the verification flag is provided and only allows self-management of the email address, resp. phone number itself.

4.x: Upgrade to >=4.11.1 3.x: Update to >=3.4.7 2.x: Update to >=3.4.7

Workarounds

The recommended solution is to upgrade to a patched version. If an upgrade is not possible, an action (v2) could be used to prevent setting the verification flag on the own user.

Questions

If there are any questions or comments about this advisory, please send an email to security@zitadel.com

Summary

ZITADEL Action V2 (introduced as early preview in 2.59.0, beta in 3.0.0 and GA in 4.0.0) is a webhook based approach to allow developers act on API request to Zitadel and customize flows such the issue of a token.

ZITADEL's Action target URLs can point to local hosts, potentially allowing adversaries to gather internal network information and connect to internal services.

Impact

When the URL points to a local host / IP address, an adversary might gather information about the internal network structure, the services exposed on internal hosts etc. This is sometimes called a Server-Side Request Forgery (SSRF).

ZITADEL Actions expect responses according to specific schemas, which reduces the threat vector.

Affected Versions

Systems running one of the following versions are affected: - 4.x: 4.0.0 through 4.11.0 (including RC version) - 3.x: 3.0.0 to 3.4.6 (including RC versions) - 2.x: 2.59.0 to 2.71.19

Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by checking the target URL against a denylist. By default localhost, resp. loopback IPs are denied.

Note that this fix was only released on v4.x. Due to the stage (preview / beta) in which the functionality was in v2.x and v3.x, the changes that have been applied to it since then and the severity, respectively the actual thread vector, a backport to the corresponding versions was not feasible. Please check the workaround section for alternative solutions if an upgrade to v4.x is not possible.

4.x: Upgrade to >=4.11.1 3.x: Update to >=v4.11.1 or check out workarounds 2.x: Update to >=v4.11.1 or check out workarounds

Workarounds

The recommended solution is to update Zitadel to a patched version.

If an upgrade is not possible, users can prevent actions from using unintended endpoints by setting network policies or firewall rules in your infrastructure. Note that this is outside of the functionality provided by ZITADEL.

Questions

If there are any questions or comments about this advisory, please send an email to security@zitadel.com

Credits

This vulnerability was found by zentrust partners GmbH during a scheduled penetration test. Thank you to the analysts Martin Tschirsich, Joud Zakharia, Christopher Baumann. The full report will be made public after the complete review.

Summary

Opaque OIDC access tokens in v2 format, truncated to 80 characters are still considered valid.

ZITADEL uses a symmetric AES encryption for opaque tokens. The cleartext payload is a concatenation of a couple of identifiers, such as a token ID and user ID. Internally Zitadel has 2 different versions of token payloads. v1 tokens are no longer created, but are still verified as to not invalidate existing session after upgrade.

The cleartext payload has a format of <tokenid>:<userid>. v2 tokens distinguished further where the tokenid is of the format v2<oidcsessionid>-at<accesstokenid>. This is an example of such a cleartext: V2354201447279099906-at354201447279165442:354201364702363650

Impact

V1 token authZ/N session data is retrieved from the database using the (simple) tokenid value and userid value. The userid (called subject in some parts of our code) was used as being the trusted user ID.

V2 token authZ/N session data is retrieved from the database using the oidcsessionid and accesstokenid and in this case the userid from the token is ignored and taken from the session data in the database.

By truncating the token to 80 chars, the userid is now missing from the cleartext of the v2 token: V2354201447279099906-at354201447279165442: The back-end still accepts this for above reasons.

This issue is not considered exploitable, but may look awkward when reproduced.

Affected Versions

All versions within the following ranges, including release candidates (RCs), are affected: - v4.x: 4.0.0 through 4.10.1 - 3.x: 3.0.0 through 3.4.6 - 2.x: 2.31.0 through 2.71.19

Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by verifying the userid from the token against the session data from the database

4.x: Upgrade to >=4.11.0 3.x: Update to >=3.4.7 2.x: Update to >=3.4.7

Workarounds

The recommended solution is to update ZITADEL to a patched version.

Questions

If there any questions or comments about this advisory, please send an email to security@zitadel.com

Credits

ZITADEL thanks Olivier Becker and Lucas Dodgson for reporting this vulnerability.

Summary

A user enumeration vulnerability has been discovered in Zitadel's login interfaces. An unauthenticated attacker can exploit this flaw to confirm the existence of valid user accounts by iterating through usernames and userIDs.

Impact

The login UIs (in version 1 and 2) provide the possibility to request a password reset, where an email will be sent to the user with a link to a verification endpoint. By submitting arbitrary userIDs to these endpoints, an attacker can differentiate between valid and invalid accounts based on the system's response.

For an effective exploit the attacker needs to iterate through the potential set of userIDs. The impact can be limited by implementing rate limiting or similar measures to limit enumeration of userIDs.

Additionally, Zitadel includes a security feature "Ignoring unknown usernames", designed to prevent username enumeration attacks by presenting a generic response for both valid and invalid usernames on the login page. The login UI V2 did not handle the setting correctly and would allow attackers to enumerate through usernames to check their existence.

Affected Versions

All versions within the following ranges, including release candidates (RCs), are affected: - v4.x: 4.0.0 through 4.9.0 - 3.x: 3.0.0 through 3.4.5 - 2.x: 2.0.0 through 2.71.19

Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by returning a generic error message, which does not indicate it the user exists.

4.x: Upgrade to >=4.9.1 3.x: Update to >=3.4.6 2.x: Update to >=3.4.6

Workarounds

The recommended solution is to update ZITADEL to a patched version. You can limit the impact by implementing rate limiting or similar measures to limit enumeration of userIDs.

There is no workaround for the "Ignoring unknown usernames" issue in login V2. Please upgrade to a patched version, if you rely on this feature.

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

Thanks to Niklas Kunz from Seamly for reporting this vulnerability from their pentest.

Summary

Zitadel's User Service discloses the total number of instance users to unauthorized users.

Impact

The ZITADEL User Service exposes the total number of users within an instance to any authenticated user, 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.

Affected Versions

Systems running one of the following version are affected:

- 4.x: 4.0.0-rc.1 through 4.7.1 - 3.x: 3.0.0-rc.1 through 3.4.4 - 2.x: 2.44.0 through 2.71.19

Patches

The vulnerability has been addressed in the latest release. The patch resolves the issue and returns the totalResult value corresponding to the number of instance users for whom the querying user has read permission.

- 4.x: Upgrade to >= 4.7.2 - 3.x: Update to >= 3.4.5 - 2.x: Update to >= 3.4.5 (or checkout the workarounds section)

Workarounds

The recommended solution is to update Zitadel to a patched version.

If a version upgrade is not possible, you can enable the permissionCheckV2 feature on your instance.

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

This vulnerability was found by zentrust partners GmbH during a scheduled penetration test. Thank you to the analysts Martin Tschirsich, Joud Zakharia, Christopher Baumann. The full report will be made public after the complete review.

Summary

A potential vulnerability exists in ZITADEL's logout endpoint in login V2. This endpoint accepts serval parameters including a postlogoutredirect. When this parameter is specified, users will be redirected to the site that is provided via this parameter. ZITADEL's login UI did not ensure that this parameter contained an allowed value and even executed passed scripts.

Impact

Zitadel is vulnerable to a DOM-Based XSS vulnerability. More specifically, the /logout endpoint insecurely routed to value that is supplied in the postlogoutredirect GET parameter. As a result, malicious JS code could be executed on Zitadel users’ browsers, in the Zitadel V2 Login domain.

An unauthenticated remote attacker can exploit this DOM-based XSS vulnerability, and thus, execute malicious JavaScript code on behalf of Zitadel users. By doing so, such an attacker could reset the password of their victims, and take over their accounts.

Note that for this to work, multiple user sessions need to be active in the same browser. Additionally, it's important to note that an account takeover is mitigated for accounts that have Multi-Factor Authentication (MFA) or Passwordless authentication enabled.

Affected Versions

Systems using the login UI (v2) and running one of the following versions are affected: - v4.x: 4.0.0-rc.1 through 4.7.0

Patches

The vulnerability has been addressed in the latest release. The patch resolves the issue by ensuring the information was passed for the ZITADEL API using a JSON Web Token (JWT). If you're running your own login UI, we recommend switching over to the new logouttoken parameter, which contains all information previously passed via specific query parameters. The contained JWT's signature needs to be verified with the instance OAuth2/OIDC public keys (jwksuri).

Before you upgrade, ensure that: - the ZITADELAPIURL is set and is pointing to your instance, resp. system in multi-instance deployments. - the HTTP host (or a x-forwarded-host) is passed in your reverse proxy to the login UI. - a x-zitadel-instance-host (or x-zitadel-forward-host) is set in your reverse for multi-instance deployments. If you're running a single instance solution, you don't need to take any actions.

Patched versions: - 4.x: Upgrade to >=4.7.1

Workarounds

The recommended solution is to update ZITADEL to a patched version.

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

Thanks to Amit Laish – GE Vernova for finding and reporting the vulnerability.

Summary

Zitadel is vulnerable to an unauthenticated, full-read SSRF vulnerability. An unauthenticated remote attacker can force Zitadel into making HTTP requests to arbitrary domains, including internal addresses. The server then returns the upstream response to the attacker, enabling data exfiltration from internal services.

Impact

ZITADEL Login UI (V2) was vulnerable to service URL manipulation through the x-zitadel-forward-host header. The service URL resolution logic treated the header as a trusted fallback for all deployments, including self-hosted instances. This allowed unauthenticated attacker to force the server to make outbound requests and read the responses, reaching internal services, exfiltrating data, and bypassing IP-based or network-segmentation controls. Affected Versions

Systems using the login UI (v2) and running one of the following versions are affected: - v4.x: 4.0.0-rc.1 through 4.7.0

Patches

The vulnerability has been addressed in the latest release. The patch resolves the issue by correctly validating the x-zitadel-forward-host, resp. all forwarded headers against the instance domains and trusted domains. It's no longer used to route traffic to the Zitadel API.

Before you upgrade, ensure that: - the ZITADELAPIURL is set and is pointing to your instance, resp. system in multi-instance deployments. - the HTTP host (or a x-forwarded-host) is passed in your reverse proxy to the login UI. - a x-zitadel-instance-host (or x-zitadel-forward-host) is set in your reverse for multi-instance deployments. If you're running a single instance solution, you don't need to take any actions.

Fixed versions: - 4.x: Upgrade to >=4.7.1

Workarounds

The recommended solution is to update ZITADEL to a patched version.

A ZITADEL fronting proxy can be configured to delete all x-zitadel-forward-host header values or set it to the requested host before sending requests to ZITADEL self-hosted environments.

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

Thanks to Amit Laish – GE Vernova for finding and reporting the vulnerability.

Summary

A vulnerability in ZITADEL's federation process allowed auto-linking users from external identity providers to existing users in ZITADEL even if the corresponding IdP was not active or if the organization did not allow federated authentication.

Impact

This vulnerability stems from the platform's failure to correctly check or enforce an organization's specific security settings during the authentication flow. An Organization Administrator can explicitly disable an IdP or disallow federation, but this setting was not being honored during the auto-linking process.

This allowed an unauthenticated attacker to initiate a login using an IdP that should have been disabled for that organization. The platform would incorrectly validate the login and, based on a matching criteria, link the attacker's external identity to an existing internal user account.

This may result in a full Account Takeover, bypassing the organization's mandated security controls. Note that accounts with MFA enabled can not be taken over by this attack. Also note that only IdPs create on an instance level would allow this to work. IdPs registered on another organization would always be denied in the (auto-)linking process.

Affected Versions

Systems running one of the following versions are affected: - v4.x: 4.0.0-rc.1 through 4.6.5 - v3.x: 3.0.0-rc.1 through 3.4.3 - v2.x: 2.50.0 through 2.71.18

Patches

The vulnerability has been addressed in the latest release. The patch resolves the issue by correctly validating the organization's login policy before auto-linking an external user.

- v4.x: Upgrade to version 4.6.6 or later. - v3.x: Update to version 3.4.4 or later. - v2.x: Update to version 2.71.19 or later.

Workarounds

Upgrading to a patched version is the recommended solution.

Questions

If you have any questions or comments about this advisory, please email Zitadel at security@zitadel.com

Credits

Thanks to Jan Kühnlein - kultify for finding and reporting the vulnerability.

Summary

A vulnerability in Zitadel's token verification prematurely marked sessions as authenticated when only one factor was verified.

Impact

Zitadel provides an API for managing sessions, enabling custom login experiences in a dedicated UI or direct integration into applications. Session Tokens are issued for active sessions, which can be used as Bearer tokens to call the Zitadel API.

Starting from 2.55.0 (see other affected versions below), Zitadel only required multi factor authentication in case the login policy has either enabled requireMFA or requireMFAForLocalUsers. If a user has set up MFA without this requirement, Zitadel would consider single factor auhtenticated sessions as valid as well and not require multiple factors.

Bypassing second authentication factors weakens multifactor authentication and enables attackers to bypass the more secure factor. An attacker can target the TOTP code alone, only six digits, bypassing password verification entirely and potentially compromising accounts with 2FA enabled.

Affected Versions

Systems using the session API (v2 beta and v2) directly or via the new login UI in the following versions are affected: - 4.x: 4.0.0 to 4.5.0 (including RC versions) - 3.x: 3.0.0 to 3.4.2 (including RC versions) - 2.x: v2.53.6 to v2.53.9, v2.54.3 to v2.54.10, 2.55.0 to 2.71.17

Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring a configured second factor regardless of the login policies requireMFA or requireMFAForLocalUsers configuration.

4.x: Upgrade to >=4.6.0 3.x: Update to >=3.4.3 2.x: Update to >=2.71.18

Workarounds

The recommended solution is to update Zitadel to a patched version.

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

This vulnerability was found by zentrust partners GmbH during a scheduled penetration test. Thank you to the analysts Martin Tschirsich, Joud Zakharia, Christopher Baumann. The full report will be made public after the complete review.

Summary

A vulnerability in Zitadel allowed brute-force attack on OTP, TOTP and password allowing to impersonate the attacked user.

Impact

An attacker can perform an online brute-force attack on OTP, TOTP, and passwords. While Zitadel allows preventing online brute force attacks in scenarios like TOTP, Email OTP, or passwords using a lockout mechanism. The mechanism is not enabled by default and can cause a denial of service for the corresponding user if enabled. Additionally, the mitigation strategies were not fully implemented in the more recent resource-based APIs.

Affected Versions

All versions within the following ranges, including release candidates (RCs), are affected: - 4.x: 4.0.0 to 4.4.0 (including RC versions) - 3.x: 3.0.0 to 3.4.2 (including RC versions) - 2.x: v2.0.0 to 2.71.17

Patches

The vulnerability has been addressed in the latest releases. The patch resolves the issue by enforcing the lockout policy on all OTP, TOTP and password checks. Additionally a “tar pit” has been introduced to slow down brute-force attacks by default. Zitadel responses will be delayed by t seconds, where t increases over the number of failed attempts within a given timeframe.

4.x: Upgrade to >=4.6.0 3.x: Update to >=3.4.3 2.x: Update to >=2.71.18

Workarounds

The recommended solution is to update Zitadel to a patched version.

The problem might be mitigated by enabling the optional logout policy ("Password maximum attempts") or by implementing more strict rate limits.

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

This vulnerability was found by zentrust partners GmbH during a scheduled penetration test. Thank you to the analysts Martin Tschirsich, Joud Zakharia, Christopher Baumann. The full report will be made public after the complete review.

Impact

A potential vulnerability exists in ZITADEL's password reset mechanism. ZITADEL utilizes the Forwarded or X-Forwarded-Host header from incoming requests to construct the URL for the password reset confirmation link. This link, containing a secret code, 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 controlled by the attacker. If the user clicks this manipulated link in the email, the secret reset code embedded in the URL can be captured by the attacker. This captured code could then be used to reset the user's password and gain unauthorized access to their account.

It's important to note that this specific attack vector is mitigated for accounts that have Multi-Factor Authentication (MFA) or Passwordless authentication enabled.

Affected Versions

Systems running one of the following versions: - 4.x: 4.0.0 to 4.5.0 (including RC versions) - 3.x: 3.0.0 to 3.4.2 (including RC versions) - 2.x: v2.0.0 to 2.71.17

Patches

Patched version ensure proper validation of the headers:

4.x: Upgrade to >=4.6.0 3.x: Update to >=3.4.3 2.x: Update to >=2.71.18

Workarounds

The recommended solution is to update ZITADEL to a patched version.

A ZITADEL fronting proxy can be configured to delete all Forwarded and X-Forwarded-Host header values before sending requests to ZITADEL self-hosted environments.

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

Thanks to Amit Laish – GE Vernova for finding and reporting the vulnerability.

The open-source identity infrastructure software Zitadel allows administrators to disable the user self-registration. Versions 4.0.0 to 4.0.2, 3.0.0 to 3.3.6, and all versions prior to 2.71.15 are vulnerable to a username enumeration issue in the login interface. The login UI includes a security feature, Ignoring unknown usernames, that is intended to prevent username enumeration by returning a generic response for both valid and invalid usernames. This vulnerability allows an unauthenticated attacker to bypass this protection by submitting arbitrary userIDs to the select account page and distinguishing between valid and invalid accounts based on the system's response. For effective exploitation, an attacker needs to iterate through possible userIDs, but the impact can be limited by implementing rate limiting or similar measures. The issue has been patched in versions 4.0.3, 3.4.0, and 2.71.15.

ZITADEL is an open source identity management system. Starting in version 2.53.0 and prior to versions 4.0.0-rc.2, 3.3.2, 2.71.13, and 2.70.14, vulnerability in ZITADEL's session management API allows any authenticated user to update a session if they know its ID, due to a missing permission check. This flaw enables session hijacking, allowing an attacker to impersonate another user and access sensitive resources. Versions prior to 2.53.0 are not affected, as they required the session token for updates. Versions 4.0.0-rc.2, 3.3.2, 2.71.13, and 2.70.14 fix the issue.

Impact

A potential vulnerability exists in ZITADEL's password reset mechanism. ZITADEL utilizes the Forwarded or X-Forwarded-Host header from incoming requests to construct the URL for the password reset confirmation link. This link, containing a secret code, 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 controlled by the attacker. If the user clicks this manipulated link in the email, the secret reset code embedded in the URL can be captured by the attacker. This captured code could then be used to reset the user's password and gain unauthorized access to their account.

It's important to note that this specific attack vector is mitigated for accounts that have Multi-Factor Authentication (MFA) or Passwordless authentication enabled.

Patches

Patched version ensure proper validation of the headers and do not allow downgrading from https to http.

3.x versions are fixed on >=3.2.2 2.71.x versions are fixed on >=2.71.11 2.x versions are fixed on >=2.70.12

Workarounds

The recommended solution is to update ZITADEL to a patched version.

A ZITADEL fronting proxy can be configured to delete all Forwarded and X-Forwarded-Host header values before sending requests to ZITADEL self-hosted environments.

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

Thanks to Amit Laish – GE Vernova for finding and reporting the vulnerability.

Impact

ZITADEL offers developers the ability to manage user sessions using the Session API. This API enables the use of IdPs for authentication, known as idp intents.

Following a successful idp intent, the client receives an id and token on a predefined URI. These id and token can then be used to authenticate the user or their session.

However, it was possible to exploit this feature by repeatedly using intents. This allowed an attacker with access to the application’s URI to retrieve the id and token, enabling them to authenticate on behalf of the user.

It’s important to note that the use of additional factors (MFA) prevents a complete authentication process and, consequently, access to the ZITADEL API.

Patches

3.x versions are fixed on >=3.0.0 2.71.x versions are fixed on >=2.71.9 2.x versions are fixed on >=2.70.10

Workarounds

The recommended solution is to update ZITADEL to a patched version.

Questions

If you have any questions or comments about this advisory, please email us at security@zitadel.com

Credits

Thanks to Józef Chraplewski from Nedap for reporting this vulnerability.