Where
AND
-Infinity
0
Severity
8.1
AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

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

1 / 2
Source: GitHub
First published (updated )
Severity
7.3
AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N

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

1 / 2
Source: GitHub
First published (updated )
Severity
6.8
Infoleak
AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N

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!

1 / 2
Source: GitHub
First published (updated )
Severity
6.5
Infoleak
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:N/A:N

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.

1 / 2
Source: GitHub
First published (updated )
Severity
6.1
XSS
AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N

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.

1 / 2
Source: GitHub
First published (updated )
Severity
5.3
AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

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

1 / 2
Source: GitHub
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203