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 OAuth2 Token Exchange endpoint allows an authenticated user or client to exchange a low-privilege access token for a token with elevated permissions at a completely different application. This bypasses the intended authorization and separation policies configured within ZITADEL.
Impact
ZITADEL enables administrators to restrict token issuance based on client permissions, project roles, and specific scopes. Due to a missing verification step during the Token Exchange flow (urn:ietf:params:oauth:grant-type:token-exchange), ZITADEL fails to validate whether the incoming access token belongs to or is authorized for the client initiating the exchange. Additionally, ZITADEL does not enforce that the newly requested scopes must stay within the boundaries of the original token's scopes.
An attacker with valid access to a low-privilege application can exploit this behavior by sending a token exchange request to a highly-privileged target application. This allows them to obtain administrative project roles, access sensitive profile data, or gain unauthorized access to other applications across the system. If public clients (which do not require client secrets) are used, this risk increases significantly as it requires no client authentication.
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 enforcing strict audience ownership verification and ensuring that requested scopes during a token exchange are restricted to a subset of the original token’s scopes.
4.x: Upgrade to $\ge$ 4.15.3 3.x: Upgrade to $\ge$ 4.15.3
Workarounds
The recommended solution is to upgrade to a patched version immediately. If an immediate upgrade is not possible, implement one of the following mitigations: - Disable via Feature Flag: Ensure the Token Exchange feature flag is explicitly turned off in your instance settings or environment variables (ZITADELDEFAULTINSTANCEFEATURESTOKENEXCHANGE=false). If the feature flag is disabled, the endpoint is unreachable and your system is not vulnerable. This is only possible in versions prior to v4.11.0, where the feature was not yet GA. - Remove the Grant Type: Ensure that the Token Exchange grant type is completely disabled or removed from all configured applications—especially high-privilege or public clients.
Questions
If you have any questions or comments about this advisory, please email us at security@zitadel.com.
Credits
Thanks to thesecguy45 and Shubham Raj / Causal Security for reporting this 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.
ZITADEL is an open source identity management platform. Prior to 3.4.12 and 4.15.2, ZITADEL's external JWT Identity Provider validation in internal/idp/providers/jwt/session.go skips the maximum token age freshness check when an incoming token omits the iat claim, allowing arbitrarily old tokens from a trusted issuer to pass authentication. This issue is fixed in versions 3.4.12 and 4.15.2.