Summary
A vulnerability in Zitadel's self-management capability allowed users to mark their email and phone as verified without going through an actual verification process.
While GHSA-282g-fhmx-xf54 (CVE-2026-27946, "Users Can Self-Verify Email/Phone via UpdateHumanUser API") closed the path that let any authenticated user mark an arbitrary email or phone as verified on their own account by calling UpdateHumanUser with email.isverified: true, additional paths were discovered.
Impact
Zitadel provides an API for managing users. The API also allows users to self-manage their own data including updating the email and phone.
Due to an improper permission check, the API allowed returning the verification code for the email and phone to the own user. This allows users to claim ownership of an email or phone they do not control and potentially bypass email-based security policies.
Note that when changing another user's email or phone, regardless of the verification flag, the permissions were correctly checked.
Affected Versions
Systems running one of the following versions are affected: - 4.x: 4.0.0 through 4.15.0 (including RC versions) - 3.x: 3.0.0 through 3.4.10 (including RC versions) - 2.x: 2.43.0 through 2.71.19
Patches
The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring the correct permission in case the verification flag is provided and only allows self-management of the email address, resp. phone number itself.
4.x: Upgrade to >=4.15.1 3.x: Update to >=3.4.11 2.x: Update to >=3.4.11
Workarounds
The recommended solution is to upgrade to a patched version. If an upgrade is not possible, an action (v2) could be used to prevent returning the verification code to the own user.
Questions
If you have any questions or comments about this advisory, please email us at security@zitadel.com
Credits
Thanks to eddieran for reporting this vulnerability.
Summary
A flaw in the external identity provider handler allows unauthorized account linking to occur under specific administrative configurations. When auto-linking by email is enabled, ZITADEL checks that the local user's email is verified, but does not explicitly cross-check whether the incoming external identity provider (IdP) also verified that email address upstream.
Impact
When a user logs in via an external identity provider, the system can automatically link them to an existing local account if their email addresses match. However, because the system fails to check if the external provider actually verified ownership of that email, a security risk is introduced if a loose or public provider is connected.
If an administrator enables email auto-linking for an external identity provider that allows anyone to sign up with an unverified email address, an attacker can exploit this behavior. By registering an account on that permissive provider using a victim's email address and logging in, the system will automatically link the attacker's federated identity to the victim's legitimate local account. This allows the attacker to log into the victim's account without requiring any interaction or confirmation from the victim.
This issue represents a configuration-dependent anomaly rather than an unconditioned attack vector. Because the scenario relies entirely on an explicit administrative choice to trust a permissive external directory and link accounts automatically based purely on email strings, the practical operational risk is classified as Medium.
Affected Versions
Systems running one of the following versions are affected:
4.x: 4.0.0 through 4.15.2 (including RC versions) 3.x: 3.0.0 through 3.4.12 (including RC versions)
Patches
The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring that the external identity provider's email verification status is explicitly validated before allowing any automatic linking logic to proceed.
4.x: Upgrade to $\ge$ 4.15.3 3.x: Upgrade to $\ge$ 4.15.3
Workarounds
If an immediate upgrade is not possible, implement one of the following mitigations:
Disable auto-linking by email entirely by setting the option to AUTOLINKINGOPTIONUNSPECIFIED on corresponding identity providers. Audit external IdP configurations and restrict email auto-linking strictly to trusted enterprise identity directories (e.g., corporate Okta or Azure AD) where email verification is strictly enforced and managed by corporate policy.
Questions
If you have any questions or comments about this advisory, please email us at security@zitadel.com
Credits
Thanks to Android-Login-Analysis and Alejandro Yadlin for reporting this vulnerability.
Summary
A token lifecycle validation vulnerability was discovered in ZITADEL's external JWT Identity Provider (IdP) implementation Specifically, within the validation pipeline, if an incoming JWT omits the exp claim entirely, the expiration block is silently skipped rather than rejected. The token is treated as valid forever.
Per the OIDC Core 1.0 specification, identity token validation pipelines must strictly handle and enforce session expiration. ZITADEL's silent acceptance of tokens missing these temporal constraints compromises session integrity.
Impact
An attacker in possession of a token lacking an exp claim holds a permanent credential with no automatic expiration or revocation window.
Affected Versions
Systems running one of the following versions are affected:
4.x: 4.0.0 through 4.15.1 (including RC versions) 3.x: 3.0.0 through 3.4.11 (including RC versions)
Patches
The vulnerability has been addressed in the latest releases. ZITADEL now explicitly rejects tokens that lack an exp claim.
4.x: Upgrade to $\ge$ 4.15.2 3.x: Upgrade to $\ge$ 3.4.12
Workarounds
The recommended solution is to update ZITADEL to a patched version.
If an immediate upgrade is not feasible, ensure at the upstream Identity Provider level that an external IdP explicitly includes the exp claim in all signed JWTs.
Publication Note
This issue was originally disclosed as part of a unified security bulletin published under GHSA-wxg7-w2v3-w38g. To satisfy CVE Numbering Authority regulations regarding independently fixable logic flaws, the missing token expiration validation (exp) has been moved into this separate tracking entry so a distinct CVE ID can be correctly mapped to it.
Questions
If there are any questions or comments about this advisory, send an email to security@zitadel.com
Credits
ZITADEL thanks Android-Login-Analysis, Jason Zhou and Pedro Giglioti for reporting this vulnerability.
Summary
A vulnerability was discovered in Zitadel's LDAP identity provider implementation, which fails to properly escape user-provided usernames before incorporating them into LDAP search filters. This allows unauthenticated attackers to perform LDAP Filter Injection during the login process.
Impact
While this vulnerability does not allow for a full authentication bypass, an attacker can use LDAP metacharacters (such as , (, )) to perform blind LDAP injection. By observing the different failure (or success) responses, an attacker can systematically enumerate valid usernames and extract sensitive attribute data from the connected LDAP directory.
Note that an authentication bypass is not possible.
Affected Versions
Systems integrating LDAP as IdPs and running one of the following versions are affected:
- 4.x: 4.0.0 through 4.14.0 (including RC versions) - 3.x: 3.1.0 through 3.4.9 - 2.x: 2.71.11 through 2.71.19
Patches
The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring the correct permission in case the verification flag is provided and only allows self-management of the email address, resp. phone number itself.
- 4.x: Upgrade to >=4.15.0 - 3.x: Update to >=3.4.10 - 2.x: Update to >=3.4.10
Workarounds
The recommended solution is to upgrade to a patched version. If an immediate upgrade is not possible, developers should ensure their project's LDAP directory has strict access controls to limit the scope of information disclosure.
Questions
If there are any questions or comments about this advisory, please send an email to security@zitadel.com
Credits
This vulnerability was identified and reported by ProScan AppSec (https://proscan.one/).
Summary
A vulnerability in Zitadel's OAuth2/OIDC interface, which allowed users to bypass organization enforcement during authentication.
Impact
Zitadel allows applications to enforce an organzation context during authentication using scopes (urn:zitadel:iam:org:id:{id} and urn:zitadel:iam:org:domain:primary:{domainname}). If enforced, a user needs to be part of the required organization to sign in.
While this was properly enforced for OAuth2/OIDC authorization requests in login V1, corresponding controls were missing for device authorization requests and all login V2 and OIDC API V2 endpoints. This allowed users to bypass the restriction and sign in with users from other organizations.
Note that this enforcement allows for an additional check during authentication and applications relying on authorizations / roles assignments are not affected by this bypass.
Affected Versions
Systems running one of the following versions are affected: - 4.x: 4.0.0 through 4.12.2 (including RC versions) - 3.x: 3.0.0 through 3.4.8 (including RC versions)
Patches
The vulnerability has been addressed in the latest releases. The patch resolves the issue by validating the provided scopes and enforcing the organization existence when processing the authorization request. Additionally it will prevent the use of a session of a user which does not belong to the required organization on the OIDC service endpoints (CreateCallback and Authorize or Deny Device Authorization endpoints).
4.x: Upgrade to >=4.12.3 3.x: Update to >=3.4.9
Workarounds
The recommended solution is to upgrade to a patched version.
Questions
If you have any questions or comments about this advisory, please email us at security@zitadel.com
Credits
Thanks to @motoki317 for reporting this vulnerability.
ZITADEL is an open source identity management platform. Prior to 3.4.8 and 4.12.2, a potential vulnerability exists in Zitadel's passkey registration endpoints. This endpoint allows registering a new passkey using a previously retrieved code. An improper expiration check of the code, could allow an attacker to potentially register their own passkey and gain access to the victim's account. This vulnerability is fixed in 3.4.8 and 4.12.2.
ZITADEL is an open source identity management platform. Prior to 3.4.8 and 4.12.2, a vulnerability in Zitadel's Management API has been reported, which allowed authenticated users holding a valid low-privilege token (e.g., project.read, project.grant.read, or project.app.read) to retrieve management-plane information belonging to other organizations by specifying a different tenant’s projectid, grantid, or appid. This vulnerability is fixed in 3.4.8 and 4.12.2.
ZITADEL is an open source identity management platform. From 2.68.0 to before 3.4.8 and 4.12.2, Zitadel provides a System for Cross-domain Identity Management (SCIM) API to provision users from external providers into Zitadel. Request to the API with URL-encoded path values were correctly routed but would bypass necessary authentication and permission checks. This allowed unauthenticated attackers to retrieve sensitive information such as names, email addresses, phone numbers, addresses, external IDs, and roles. Note that due to additional checks when manipulating data, an attacker could not modify or delete any user data. This vulnerability is fixed in 3.4.8 and 4.12.2.
ZITADEL is an open source identity management platform. From version 4.0.0-rc.1 to 4.7.0, a potential vulnerability exists in ZITADEL's password reset mechanism in login V2. ZITADEL utilizes the Forwarded or X-Forwarded-Host header from incoming requests to construct the URL for the password reset confirmation link. This link, containing a secret code, is then emailed to the user. This issue has been patched in version 4.7.1.
Summary
A vulnerability in Zitadel's login V2 interface was discovered, allowing for possible account takeover.
Impact
Zitadel allows organization administrators to change the default redirect URI for their organization. This setting enables them to redirect users to an arbitrary location after they log in.
Due to missing restrictions and improper handling, malicious javascrtipt code could be executed in Zitadel login UI (v2) using the users’ browser.
An unauthenticated remote attacker can exploit this Stored XSS vulnerability, reset the password of their victims, and take over their accounts.
It's important to note that this specific attack vector is mitigated for accounts that have Multi-Factor Authentication (MFA) or Passwordless authentication enabled.Stored XSS vulnerability.
Affected Versions
Systems running one of the following versions are affected: - 4.x: 4.0.0 through 4.11.1 (including RC versions)
Patches
The vulnerability has been addressed in the latest releases. The login UI prevents execution of such code. Additionally, the page to change the password, now always requires the user's current password regardless of the state of the authenticated session.
4.x: Upgrade to >= 4.12.0
Workarounds
The recommended solution is to upgrade to a patched version.
Questions
If there are any questions or comments about this advisory, please send an email to security@zitadel.com
Credits
ZITADEL extends thanks once again to Amit Laish from GE Vernova for finding and reporting the vulnerability.
Summary
A vulnerability in Zitadel's login V2 UI allowed users to bypass login behavior and security policies and self-register new accounts or sign in using password even if corresponding options were disabled in their organizaton.
Impact
Zitadel enables administrators to configure their organization’s login behavior and security policies. As part of this functionality, they can disable user self-registration, enforce passwordless logins only, and more.
Due to improper enforcement an attacker could send direct HTTP requests to the login UI and create accounts in organizations that have disabled user self-registration, and gain unauthorized access to the system. The same attack vector could be used to authenticate for example using username and password even when this login method was disabled.
Affected Versions
Systems running one of the following versions are affected: - 4.x: 4.0.0 through 4.12.0 (including RC versions)
Patches
The vulnerability has been addressed in the latest releases. The patch resolves the issue by enforcing the policies on the logiin UI server.
4.x: Upgrade to >=4.12.1
Workarounds
The recommended solution is to upgrade to a patched version.
Questions
If there are any questions or comments about this advisory, please send an email to security@zitadel.com
Credits
ZITADEL extends thanks once again to Amit Laish from GE Vernova for finding and reporting the vulnerability.
Summary
A vulnerability was discovered in Zitadel's login V2 interface that allowed a possible account takeover.
Impact
Zitadel exposes an HTTP endpoint named /saml-post. This endpoint is used for handling requests to SAML IdPs and accepts two HTTP GET parameters: url and id. When these parameters are supplied, users’ browsers auto-submit an HTTP POST request to the provided url parameter. The endpoint insecurely redirects users using the provided url GET parameter. As a result, by specifying a javascript: scheme, malicious JS code could be executed on Zitadel users’ browsers.
The endpoint also reflects user-supplied input in the server response, without HTML-encoding it. As a result, it is possible to inject arbitrary HTML code, which again leads to malicious JS code execution in the Zitadel users’ browsers.
An unauthenticated remote attacker can exploit these XSS vulnerabilities, and thus, execute malicious JavaScript code on behalf of Zitadel users. By doing so, such an attacker could reset the password of their victims, and take over their accounts.
It's important to note that this specific attack vector is mitigated for accounts that have Multi-Factor Authentication (MFA) or Passwordless authentication enabled.
Affected Versions
Systems running one of the following versions are affected: - 4.x: 4.0.0 through 4.11.1 (including RC versions) Important Note: Although this /saml-post endpoint is used when Zitadel is integrated with a SAML Identity Provider (IdP), the vulnerability in this finding does not require Zitadel to be configured with a SAML IdP. Consequently, Zitadel is vulnerable in its default, out-of-the-box configuration.
Patches
The vulnerability has been addressed in the latest releases. The patch reworked the integration of SAML IdPs and the /saml-post endpoint no longer exists. Additionally, the page to change the password, now always requires the user's current password regardless of the state of the authenticated session.
4.x: Upgrade to >= 4.12.0
Workarounds
The recommended solution is to upgrade to a patched version. If an upgrade is not possible and no SAML IdP integration is needed, a WAF or reverse proxy rule can be deployed to prevent access to the endpoint.
Questions
If there are any questions or comments about this advisory, please email them to security@zitadel.com
Credits
ZITADEL extends thanks once again to Amit Laish from GE Vernova for finding and reporting the vulnerability.
Summary
A vulnerability in ZITADEL's self-management capability allowed users to mark their email and phone as verified without going through an actual verification process.
Impact
ZITADEL provides an API for managing users. The API also allows users to self-manage their own data including updating the email and phone.
Due to an improper permission check, the API allowed setting the verified flag for the email and phone on the own user. This allows users to claim ownership of an email or phone they do not control and potentially bypass email-based security policies.
Note that when changing another user's email or phone, regardless of the verification flag, the permissions were correctly checked.
Affected Versions
Systems running one of the following versions are affected: - 4.x: 4.0.0 through 4.11.0 (including RC versions) - 3.x: 3.0.0 through 3.4.6 (including RC versions) - 2.x: 2.43.0 through 2.71.19
Patches
The vulnerability has been addressed in the latest releases. The patch resolves the issue by requiring the correct permission in case the verification flag is provided and only allows self-management of the email address, resp. phone number itself.
4.x: Upgrade to >=4.11.1 3.x: Update to >=3.4.7 2.x: Update to >=3.4.7
Workarounds
The recommended solution is to upgrade to a patched version. If an upgrade is not possible, an action (v2) could be used to prevent setting the verification flag on the own user.
Questions
If there are any questions or comments about this advisory, please send an email to security@zitadel.com
Summary
ZITADEL Action V2 (introduced as early preview in 2.59.0, beta in 3.0.0 and GA in 4.0.0) is a webhook based approach to allow developers act on API request to Zitadel and customize flows such the issue of a token.
ZITADEL's Action target URLs can point to local hosts, potentially allowing adversaries to gather internal network information and connect to internal services.
Impact
When the URL points to a local host / IP address, an adversary might gather information about the internal network structure, the services exposed on internal hosts etc. This is sometimes called a Server-Side Request Forgery (SSRF).
ZITADEL Actions expect responses according to specific schemas, which reduces the threat vector.
Affected Versions
Systems running one of the following versions are affected: - 4.x: 4.0.0 through 4.11.0 (including RC version) - 3.x: 3.0.0 to 3.4.6 (including RC versions) - 2.x: 2.59.0 to 2.71.19
Patches
The vulnerability has been addressed in the latest releases. The patch resolves the issue by checking the target URL against a denylist. By default localhost, resp. loopback IPs are denied.
Note that this fix was only released on v4.x. Due to the stage (preview / beta) in which the functionality was in v2.x and v3.x, the changes that have been applied to it since then and the severity, respectively the actual thread vector, a backport to the corresponding versions was not feasible. Please check the workaround section for alternative solutions if an upgrade to v4.x is not possible.
4.x: Upgrade to >=4.11.1 3.x: Update to >=v4.11.1 or check out workarounds 2.x: Update to >=v4.11.1 or check out workarounds
Workarounds
The recommended solution is to update Zitadel to a patched version.
If an upgrade is not possible, users can prevent actions from using unintended endpoints by setting network policies or firewall rules in your infrastructure. Note that this is outside of the functionality provided by ZITADEL.
Questions
If there are any questions or comments about this advisory, please send an email to security@zitadel.com
Credits
This vulnerability was found by zentrust partners GmbH during a scheduled penetration test. Thank you to the analysts Martin Tschirsich, Joud Zakharia, Christopher Baumann. The full report will be made public after the complete review.
Summary
Opaque OIDC access tokens in v2 format, truncated to 80 characters are still considered valid.
ZITADEL uses a symmetric AES encryption for opaque tokens. The cleartext payload is a concatenation of a couple of identifiers, such as a token ID and user ID. Internally Zitadel has 2 different versions of token payloads. v1 tokens are no longer created, but are still verified as to not invalidate existing session after upgrade.
The cleartext payload has a format of <tokenid>:<userid>. v2 tokens distinguished further where the tokenid is of the format v2<oidcsessionid>-at<accesstokenid>. This is an example of such a cleartext: V2354201447279099906-at354201447279165442:354201364702363650
Impact
V1 token authZ/N session data is retrieved from the database using the (simple) tokenid value and userid value. The userid (called subject in some parts of our code) was used as being the trusted user ID.
V2 token authZ/N session data is retrieved from the database using the oidcsessionid and accesstokenid and in this case the userid from the token is ignored and taken from the session data in the database.
By truncating the token to 80 chars, the userid is now missing from the cleartext of the v2 token: V2354201447279099906-at354201447279165442: The back-end still accepts this for above reasons.
This issue is not considered exploitable, but may look awkward when reproduced.
Affected Versions
All versions within the following ranges, including release candidates (RCs), are affected: - v4.x: 4.0.0 through 4.10.1 - 3.x: 3.0.0 through 3.4.6 - 2.x: 2.31.0 through 2.71.19
Patches
The vulnerability has been addressed in the latest releases. The patch resolves the issue by verifying the userid from the token against the session data from the database
4.x: Upgrade to >=4.11.0 3.x: Update to >=3.4.7 2.x: Update to >=3.4.7
Workarounds
The recommended solution is to update ZITADEL to a patched version.
Questions
If there any questions or comments about this advisory, please send an email to security@zitadel.com
Credits
ZITADEL thanks Olivier Becker and Lucas Dodgson for reporting this vulnerability.
Summary
A user enumeration vulnerability has been discovered in Zitadel's login interfaces. An unauthenticated attacker can exploit this flaw to confirm the existence of valid user accounts by iterating through usernames and userIDs.
Impact
The login UIs (in version 1 and 2) provide the possibility to request a password reset, where an email will be sent to the user with a link to a verification endpoint. By submitting arbitrary userIDs to these endpoints, an attacker can differentiate between valid and invalid accounts based on the system's response.
For an effective exploit the attacker needs to iterate through the potential set of userIDs. The impact can be limited by implementing rate limiting or similar measures to limit enumeration of userIDs.
Additionally, Zitadel includes a security feature "Ignoring unknown usernames", designed to prevent username enumeration attacks by presenting a generic response for both valid and invalid usernames on the login page. The login UI V2 did not handle the setting correctly and would allow attackers to enumerate through usernames to check their existence.
Affected Versions
All versions within the following ranges, including release candidates (RCs), are affected: - v4.x: 4.0.0 through 4.9.0 - 3.x: 3.0.0 through 3.4.5 - 2.x: 2.0.0 through 2.71.19
Patches
The vulnerability has been addressed in the latest releases. The patch resolves the issue by returning a generic error message, which does not indicate it the user exists.
4.x: Upgrade to >=4.9.1 3.x: Update to >=3.4.6 2.x: Update to >=3.4.6
Workarounds
The recommended solution is to update ZITADEL to a patched version. You can limit the impact by implementing rate limiting or similar measures to limit enumeration of userIDs.
There is no workaround for the "Ignoring unknown usernames" issue in login V2. Please upgrade to a patched version, if you rely on this feature.
Questions
If you have any questions or comments about this advisory, please email us at security@zitadel.com
Credits
Thanks to Niklas Kunz from Seamly for reporting this vulnerability from their pentest.
Summary
Zitadel's User Service discloses the total number of instance users to unauthorized users.
Impact
The ZITADEL User Service exposes the total number of users within an instance to any authenticated user, regardless of their specific permissions. While this does not leak individual user data or PII, disclosing the total user count via the totalResult field constitutes an information disclosure vulnerability that may be sensitive in certain contexts.
Affected Versions
Systems running one of the following version are affected:
- 4.x: 4.0.0-rc.1 through 4.7.1 - 3.x: 3.0.0-rc.1 through 3.4.4 - 2.x: 2.44.0 through 2.71.19
Patches
The vulnerability has been addressed in the latest release. The patch resolves the issue and returns the totalResult value corresponding to the number of instance users for whom the querying user has read permission.
- 4.x: Upgrade to >= 4.7.2 - 3.x: Update to >= 3.4.5 - 2.x: Update to >= 3.4.5 (or checkout the workarounds section)
Workarounds
The recommended solution is to update Zitadel to a patched version.
If a version upgrade is not possible, you can enable the permissionCheckV2 feature on your instance.
Questions
If you have any questions or comments about this advisory, please email us at security@zitadel.com
Credits
This vulnerability was found by zentrust partners GmbH during a scheduled penetration test. Thank you to the analysts Martin Tschirsich, Joud Zakharia, Christopher Baumann. The full report will be made public after the complete review.
Summary
A potential vulnerability exists in ZITADEL's logout endpoint in login V2. This endpoint accepts serval parameters including a postlogoutredirect. When this parameter is specified, users will be redirected to the site that is provided via this parameter. ZITADEL's login UI did not ensure that this parameter contained an allowed value and even executed passed scripts.
Impact
Zitadel is vulnerable to a DOM-Based XSS vulnerability. More specifically, the /logout endpoint insecurely routed to value that is supplied in the postlogoutredirect GET parameter. As a result, malicious JS code could be executed on Zitadel users’ browsers, in the Zitadel V2 Login domain.
An unauthenticated remote attacker can exploit this DOM-based XSS vulnerability, and thus, execute malicious JavaScript code on behalf of Zitadel users. By doing so, such an attacker could reset the password of their victims, and take over their accounts.
Note that for this to work, multiple user sessions need to be active in the same browser. Additionally, it's important to note that an account takeover is mitigated for accounts that have Multi-Factor Authentication (MFA) or Passwordless authentication enabled.
Affected Versions
Systems using the login UI (v2) and running one of the following versions are affected: - v4.x: 4.0.0-rc.1 through 4.7.0
Patches
The vulnerability has been addressed in the latest release. The patch resolves the issue by ensuring the information was passed for the ZITADEL API using a JSON Web Token (JWT). If you're running your own login UI, we recommend switching over to the new logouttoken parameter, which contains all information previously passed via specific query parameters. The contained JWT's signature needs to be verified with the instance OAuth2/OIDC public keys (jwksuri).
Before you upgrade, ensure that: - the ZITADELAPIURL is set and is pointing to your instance, resp. system in multi-instance deployments. - the HTTP host (or a x-forwarded-host) is passed in your reverse proxy to the login UI. - a x-zitadel-instance-host (or x-zitadel-forward-host) is set in your reverse for multi-instance deployments. If you're running a single instance solution, you don't need to take any actions.
Patched versions: - 4.x: Upgrade to >=4.7.1
Workarounds
The recommended solution is to update ZITADEL to a patched version.
Questions
If you have any questions or comments about this advisory, please email us at security@zitadel.com
Credits
Thanks to Amit Laish – GE Vernova for finding and reporting the vulnerability.
Summary
Zitadel is vulnerable to an unauthenticated, full-read SSRF vulnerability. An unauthenticated remote attacker can force Zitadel into making HTTP requests to arbitrary domains, including internal addresses. The server then returns the upstream response to the attacker, enabling data exfiltration from internal services.
Impact
ZITADEL Login UI (V2) was vulnerable to service URL manipulation through the x-zitadel-forward-host header. The service URL resolution logic treated the header as a trusted fallback for all deployments, including self-hosted instances. This allowed unauthenticated attacker to force the server to make outbound requests and read the responses, reaching internal services, exfiltrating data, and bypassing IP-based or network-segmentation controls. Affected Versions
Systems using the login UI (v2) and running one of the following versions are affected: - v4.x: 4.0.0-rc.1 through 4.7.0
Patches
The vulnerability has been addressed in the latest release. The patch resolves the issue by correctly validating the x-zitadel-forward-host, resp. all forwarded headers against the instance domains and trusted domains. It's no longer used to route traffic to the Zitadel API.
Before you upgrade, ensure that: - the ZITADELAPIURL is set and is pointing to your instance, resp. system in multi-instance deployments. - the HTTP host (or a x-forwarded-host) is passed in your reverse proxy to the login UI. - a x-zitadel-instance-host (or x-zitadel-forward-host) is set in your reverse for multi-instance deployments. If you're running a single instance solution, you don't need to take any actions.
Fixed versions: - 4.x: Upgrade to >=4.7.1
Workarounds
The recommended solution is to update ZITADEL to a patched version.
A ZITADEL fronting proxy can be configured to delete all x-zitadel-forward-host header values or set it to the requested host before sending requests to ZITADEL self-hosted environments.
Questions
If you have any questions or comments about this advisory, please email us at security@zitadel.com
Credits
Thanks to Amit Laish – GE Vernova for finding and reporting the vulnerability.
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 open-source identity infrastructure software. ZITADEL administrators can enable a setting called "Ignoring unknown usernames" which helps mitigate attacks that try to guess/enumerate usernames. If enabled, ZITADEL will show the password prompt even if the user doesn't exist and report "Username or Password invalid". While the setting was correctly respected during the login flow, the user's username was normalized leading to a disclosure of the user's existence. 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 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
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!
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'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'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 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.
Impact
ZITADEL administrators can enable a setting called "Ignoring unknown usernames" which helps mitigate attacks that try to guess/enumerate usernames. If enabled, ZITADEL will show the password prompt even if the user doesn't exist and report "Username or Password invalid". Due to a implementation change to prevent deadlocks calling the database, the flag would not be correctly respected in all cases and an attacker would gain information if an account exist within ZITADEL, since the error message shows "object not found" instead of the generic error message.
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
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
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.
Impact
In case ZITADEL could not connect to the database, connection information including db name, username and db host name could be returned to the user.
Patches
2.x versions are fixed on >= 2.50.3 2.49.x versions are fixed on >= 2.49.5 2.48.x versions are fixed on >= 2.48.5 2.47.x versions are fixed on >= 2.47.10 2.46.x versions are fixed on >= 2.46.7 2.45.x versions are fixed on >= 2.45.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