GHSA-pvm5-9frx-264r CVE-2026-23511 GO-2026-4319

Zitadel has a user enumeration vulnerability in Login UIs

Medium Go

Severity: 5.3 / 10; Medium · CVSS 3.1
Exploit chance (EPSS): 0.40%; Chance of exploitation in the next 30 days. Higher than 34.45% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-203 Observable Discrepancy; CWE-204 Observable Response Discrepancy
Fix: 4.9.1; Upgrade github.com/zitadel/zitadel to this version or later

Description

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.

Affected versions

Go

Package	Vulnerable	Fixed in
github.com/zitadel/zitadel	`>= 4.0.0, < 4.9.1`	`4.9.1`
github.com/zitadel/zitadel	`< 3.4.6`	`3.4.6`
github.com/zitadel/zitadel	`all versions`	No fix yet

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

github.com/zitadel/zitadel Go → `4.9.1`

go

go get github.com/zitadel/zitadel@v4.9.1 && go mod tidy

Severity breakdown

CVSS 3.1 5.3

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

Attack vector: Network
Attack complexity: Low
Privileges required: None
User interaction: None
Scope: Unchanged
Confidentiality: Low
Integrity: None
Availability: None

Weakness

CWE-203: Observable Discrepancy

The product behaves differently or sends different responses under different circumstances in a way that is observable to an unauthorized actor.

How to prevent it

Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
Implementation: Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.

CWE-204: Observable Response Discrepancy

The product provides different responses to incoming requests in a way that reveals internal state information to an unauthorized actor outside of the intended control sphere.

How to prevent it

Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
Implementation: Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.

References

Advisories

nvd.nist.gov/vuln/detail/CVE-2026-23511

Packages

github.com/zitadel/zitadel

Timeline

Jan 15, 2026 Published
Jun 17, 2026 Last updated by the source
Oct 31, 2026 Latest EPSS score

Advisory	Severity	Why it's related
GHSA-fgmf-7rf8-m6vf ZITADEL: Actions V1 sandbox escape: host file read via require()	High	Also affects github.com/zitadel/zitadel
GHSA-9993-rfwp-rhwf ZITADEL: MFA bypass via session reuse in Login V2	High	Also affects github.com/zitadel/zitadel
GHSA-v859-c572-qh5p ZITADEL: Improper Role Revocation on Granted Projects during Multiple Role Deletions	Medium	Also affects github.com/zitadel/zitadel
GHSA-jq8w-8q2f-ffm9 ZITADEL Users Can Self-Verify Email/Phone via API	High	Also affects github.com/zitadel/zitadel
GHSA-vrh8-c9cm-wh8v ZITADEL: Unauthorized Token Privilege Escalation in OAuth2 Token Exchange	High	Also affects github.com/zitadel/zitadel
GHSA-992q-9gwp-7r79 ZITADEL: Auto-linking by email: IdP-side email verification is not checked	Medium	Also affects github.com/zitadel/zitadel
GHSA-v77h-2w3m-94hx ZITADEL: Missing Token Expiration (`exp`) Validation in JWT IdP Provider	Medium	Also affects github.com/zitadel/zitadel
GHSA-g5h5-m4hm-xjrr ZITADEL: Missing Token Audience Validation (`aud`) in JWT IdP Provider	Medium	Also affects github.com/zitadel/zitadel

Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor