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