GHSA-rxvx-hhpj-q6px CVE-2026-44671 GO-2026-5648

ZITADEL has LDAP Filter Injection in Login Flow

High Go

Severity: 7.5 / 10; High · CVSS 3.1
Exploit chance (EPSS): 0.48%; Chance of exploitation in the next 30 days. Higher than 41.37% of scored vulnerabilities.
Known exploited: No; Not in CISA's catalog
Weakness: CWE-90 Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
Fix: 4.15.0; Upgrade github.com/zitadel/zitadel to this version or later

Description

Summary

A vulnerability was discovered in Zitadel's LDAP identity provider implementation, which fails to properly escape user-provided usernames before incorporating them into LDAP search filters. This allows unauthenticated attackers to perform LDAP Filter Injection during the login process.

Impact

While this vulnerability does not allow for a full authentication bypass, an attacker can use LDAP metacharacters (such as *, (, )) to perform blind LDAP injection. By observing the different failure (or success) responses, an attacker can systematically enumerate valid usernames and extract sensitive attribute data from the connected LDAP directory.

Note that an authentication bypass is not possible.

Affected Versions

Systems integrating LDAP as IdPs and running one of the following versions are affected:

4.x: 4.0.0 through 4.14.0 (including RC versions)
3.x: 3.1.0 through 3.4.9
2.x: 2.71.11 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.15.0
3.x: Update to >=3.4.10
2.x: Update to >=3.4.10

Workarounds

The recommended solution is to upgrade to a patched version. If an immediate upgrade is not possible, developers should ensure their project's LDAP directory has strict access controls to limit the scope of information disclosure.

Questions

If there are any questions or comments about this advisory, please send an email to security@zitadel.com

Credits

This vulnerability was identified and reported by ProScan AppSec (https://proscan.one/).

Affected versions

Go

Package	Vulnerable	Fixed in
github.com/zitadel/zitadel	`>= 4.0.0, < 4.15.0`	`4.15.0`
github.com/zitadel/zitadel	`>= 2.71.11, <= 2.71.19`	No fix yet
github.com/zitadel/zitadel	`>= 3.1.0, < 3.4.10`	`3.4.10`
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.15.0`

go

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

Severity breakdown

CVSS 3.1 7.5

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

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

Weakness

CWE-90: Improper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')

The product constructs all or part of an LDAP query using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended LDAP query when it is sent to a downstream component.

How to prevent it

Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.

References

Advisories

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

Packages

github.com/zitadel/zitadel

Timeline

May 8, 2026 Published
Jun 25, 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