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