Advisories for Golang/Github.com/Zitadel/Zitadel/V2 package

A vulnerability in Zitadel's login V2 interface was discovered, allowing for possible account takeover.

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.

A vulnerability was discovered in Zitadel's login V2 interface that allowed a possible account takeover.

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.

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.

A potential vulnerability exists in ZITADEL's logout endpoint in login V2. This endpoint accepts serval parameters including a post_logout_redirect. 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.

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.

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.

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 …

A vulnerability in Zitadel's token verification prematurely marked sessions as authenticated when only one factor was verified.

A vulnerability in Zitadel allowed brute-force attack on OTP, TOTP and password allowing to impersonate the attacked user.

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 …

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 …

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.

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.

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.

This advisory duplicates another.

This advisory duplicates another.

This advisory duplicates another.