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
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 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.
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.
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
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.
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.
Impact
ZITADEL's user grants deactivation mechanism did not work correctly. Deactivated user grants were still provided in token, which could lead to unauthorized access to applications and resources. Additionally, the management and auth API always returned the state as active or did not provide any information about the state.
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
Unpatched versions can explicitly remove the user grants to make sure the user does not get access anymore.
Questions
If you have any questions or comments about this advisory, please email us at security@zitadel.com
Impact
ZITADEL provides administrators the possibility to define a Lockout Policy with a maximum amount of failed password check attempts. On every failed password check, the amount of failed checks is compared against the configured maximum. Exceeding the limit, will lock the user and prevent further authentication.
In the affected implementation it was possible for an attacker to start multiple parallel password checks, giving him the possibility to try out more combinations than configured in the Lockout Policy.
Patches
2.x versions are fixed on >= 2.40.5 2.38.x versions are fixed on >= 2.38.3
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
Summary In Zitadel, even after an organization is deactivated, associated projects, respectively their applications remain active. Users across other organizations can still log in and access through these applications, leading to unauthorized access. Additionally, if a project was deactivated access to applications was also still possible.
Details The issue stems from the fact that when an organization is deactivated in Zitadel, the applications associated with it do not automatically deactivate. The application lifecycle is not tightly coupled with the organization's lifecycle, leading to a situation where the organization or project is marked as inactive, but its resources remain accessible.
PoC - Create a new Organization, create new project and setup OpenID connect. - Deactivate an Organization - Setup authentication without selecting Check for Project on Authentication - User is able to login despite the organization is deactivated
Impact This vulnerability allows for unauthorized access to projects and their resources, which should have been restricted post-organization deactivation.
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
Workaround Unpatched versions can explicitly disable the application to make sure the client is not allowed anymore.
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!
Impact
ZITADEL provides users the ability to list all user sessions of the current user agent (browser) by API and in the Console UI.
Due to a missing check, user sessions without that information (e.g. when created though the session service) were incorrectly listed exposing potentially other user's sessions.
Note that the Login UI was never affected and there was no possibility to take over such a session.
Patches
2.x versions are fixed on >= 2.55.1 2.54.x versions are fixed on >= 2.54.5 2.53.x versions are fixed on >= 2.53.8
ZITADEL recommends upgrading to the latest versions available in due course.
Workarounds
There is no workaround since a patch is already available.
References
- https://github.com/zitadel/zitadel/pull/8231 - https://discord.com/channels/927474939156643850/1254096852937347153 - https://github.com/zitadel/zitadel/issues/8213
Questions If you have any questions or comments about this advisory, please email us at security@zitadel.com
Credits Thanks to @cybertransformer, @Avolicious, @AmirhoseinBrz and @srividyaj for finding and reporting the vulnerability.
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.
Impact Under certain circumstances an action could set reserved claims managed by ZITADEL.
For example it would be possible to set the claim urn:zitadel:iam:user:resourceowner:name
json {"urn:zitadel:iam:user:resourceowner:name": "ACME"}
if it was not set by ZITADEL itself.
To compensate for this we introduced a protection that does prevent actions from changing claims that start with urn:zitadel:iam
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
Workarounds No workaround available since a patch is available
Credits Many thanks to @schettn whose disclosure of another topic lead us to find this issue.
Impact
ZITADEL uses HTML for emails and renders certain information such as usernames dynamically. That information can be entered by users or administrators. Due to a missing output sanitization, these emails could include malicious code. This may potentially lead to a threat where an attacker, without privileges, could send out altered notifications that are part of the registration processes. An attacker could create a malicious link, where the injected code would be rendered as part of the email.
During investigation of this issue a related issue was found and mitigated, where on the user's detail page the username was not sanitized and would also render HTML, giving an attacker the same vulnerability.
While it was possible to inject HTML including javascript, the execution of such scripts would be prevented by most email clients and the Content Security Policy in Console UI.
Patches
2.x versions are fixed on >= 2.58.1 2.57.x versions are fixed on >= 2.57.1 2.56.x versions are fixed on >= 2.56.2 2.55.x versions are fixed on >= 2.55.5 2.54.x versions are fixed on >= 2.54.8 2.53.x versions are fixed on >= 2.53.9 2.52.x versions are fixed on >= 2.52.9
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 Sushmita Poudel and David Underwood for reporting this.