CWE-90
AllowedImproper Neutralization of Special Elements used in an LDAP Query ('LDAP Injection')
Abstraction: Base · Status: Draft
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.
135 vulnerabilities reference this CWE, most recent first.
GHSA-5G3M-GVFM-WFX3
Vulnerability from github – Published: 2026-08-20 00:35 – Updated: 2026-08-20 00:35In versions below 2.3.8 of the AD LDAP app for Splunk SOAR, a user who holds a role with permission to run actions could inject crafted input into an Active Directory query to enumerate Active Directory objects, including accounts, groups, and organizational units, read sensitive attributes from arbitrary directory objects, and redirect account modification actions to unintended objects. For more information see Run an action in Splunk SOAR (https://help.splunk.com/en/splunk-soar/soar-on-premises/use-splunk-soar-on-premises/8.6.0/use-the-command-line-interface-to-perform-tasks-in-splunk-soar-on-premises/run-an-action-in-splunk-soar-on-premises).
{
"affected": [],
"aliases": [
"CVE-2026-76373"
],
"database_specific": {
"cwe_ids": [
"CWE-90"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-19T22:17:23Z",
"severity": "MODERATE"
},
"details": "In versions below 2.3.8 of the AD LDAP app for Splunk SOAR, a user who holds a role with permission to run actions could inject crafted input into an Active Directory query to enumerate Active Directory objects, including accounts, groups, and organizational units, read sensitive attributes from arbitrary directory objects, and redirect account modification actions to unintended objects. For more information see Run an action in Splunk SOAR (https://help.splunk.com/en/splunk-soar/soar-on-premises/use-splunk-soar-on-premises/8.6.0/use-the-command-line-interface-to-perform-tasks-in-splunk-soar-on-premises/run-an-action-in-splunk-soar-on-premises).",
"id": "GHSA-5g3m-gvfm-wfx3",
"modified": "2026-08-20T00:35:03Z",
"published": "2026-08-20T00:35:03Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-76373"
},
{
"type": "WEB",
"url": "https://advisory.splunk.com/advisories/SVD-2026-0806"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-69RR-JVGQ-G678
Vulnerability from github – Published: 2026-04-02 09:30 – Updated: 2026-04-16 21:31SEPPmail Secure Email Gateway before version 15.0.3 allows attackers with a specially crafted email address to read the contents of emails encrypted for other users.
{
"affected": [],
"aliases": [
"CVE-2026-29131"
],
"database_specific": {
"cwe_ids": [
"CWE-90"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-02T09:16:21Z",
"severity": "MODERATE"
},
"details": "SEPPmail Secure Email Gateway before version 15.0.3 allows attackers with a specially crafted email address to read the contents of emails encrypted for other users.",
"id": "GHSA-69rr-jvgq-g678",
"modified": "2026-04-16T21:31:09Z",
"published": "2026-04-02T09:30:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-29131"
},
{
"type": "WEB",
"url": "https://downloads.seppmail.com/extrelnotes/150/ERN15.0.html#seppmail-vulnerability-disclosure-1503"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-6MWX-4547-5VC9
Vulnerability from github – Published: 2026-06-19 21:42 – Updated: 2026-06-19 21:421. Description
Component
sdk/helper/ldaputil/client.go — the shared LDAP utility library used by both the LDAP authentication backend and OpenLDAP secrets engine to construct LDAP search filters and bind DNs.
Root Cause
The LDAP utility contains a function selection error that causes incorrect escaping of user-controlled input in LDAP filter construction. Two lines construct the bindDN using EscapeLDAPValue():
// Line 191 — UPN Domain path
bindDN = fmt.Sprintf("%s@%s", EscapeLDAPValue(username), cfg.UPNDomain)
// Line 193 — User DN path
bindDN = fmt.Sprintf("%s=%s,%s", cfg.UserAttr, EscapeLDAPValue(username), cfg.UserDN)
The problem: EscapeLDAPValue() implements RFC 4514 escaping, which is designed for Distinguished Name (DN) components. It only escapes characters meaningful in DNs: +, ,, ;, ", \, <, >, and leading/trailing spaces.
LDAP search filters (RFC 4515) have a different set of special characters: *, (, ), \, and NUL (\x00). None of these are escaped by EscapeLDAPValue(). The correct function is ldap.EscapeFilter() from the github.com/go-ldap/ldap/v3 package.
The irony: the same file uses ldap.EscapeFilter() correctly at lines 225-226 in RenderUserSearchFilter() for the UserFilter template path, but the GetUserDN() function at lines 191-193 uses the wrong escape function.
Exploitation Mechanics
Username: alice)(objectClass=*
↓ EscapeLDAPValue (no-op — no DN special chars)
alice)(objectClass=*
↓ fmt.Sprintf("(&(objectClass=user)(sAMAccountName=%s))", escapedUsername)
(&(objectClass=user)(sAMAccountName=alice)(objectClass=*))
^^ injection point
The filter (&(objectClass=user)(sAMAccountName=alice)(objectClass=*)) is logically equivalent to:
- sAMAccountName=alice AND objectClass=user AND objectClass=*
Since all entries match objectClass=*, the filter matches any user entry where sAMAccountName is alice, effectively ignoring the objectClass=user constraint. By crafting more sophisticated injections (e.g., alice)(|(sAMAccountName=admin), the attacker can match arbitrary different user entries.
Preconditions
- LDAP authentication backend must be configured
- Directory must be Active Directory (UPNDomain path) or use UserDN/UserAttr binding
- Attacker controls the
usernamefield at login time
2. Proof of Concept
# Login with LDAP injection payload as username
curl -k -X POST \
-H "Content-Type: application/json" \
-d '{
"username": "alice)(sAMAccountName=*",
"password": "anything"
}' \
https://localhost:8200/v1/auth/ldap/login/admin
# LDAP filter constructed:
# (&(objectClass=user)(sAMAccountName=alice)(sAMAccountName=*))
# injection ──────────^
# The filter matches the first user with objectClass=user
# If the LDAP server returns admin's entry first, the token
# is bound to the admin entity, inheriting all admin policies
The LDAP search returns whichever entry the server ranks highest among results. In Active Directory with default sorting, this is often the oldest or alphabetically first user — potentially an administrative account.
3. Impact
| Impact | Detail |
|---|---|
| Confidentiality | Token bound to a different LDAP user (e.g., admin) grants access to all secrets and policies belonging to that entity |
| Integrity | Ability to modify secrets, write policies, or configure backends as the impersonated user |
| Availability | Low direct impact, but administrative access enables disabling or misconfiguring the entire OpenBao instance |
Likelihood: HIGH — the escape function mismatch is a well-documented antipattern in OWASP LDAP Injection guidance. The attack is trivially exploitable with no special tooling beyond curl.
Why This Is High Severity
The LDAP auth backend is frequently used as a primary authentication method for enterprise OpenBao deployments. A successful LDAP injection against this backend can bypass the entire authentication chain, granting administrative access to the secrets store without needing to compromise an actual admin account.
4. Remediation
Primary Fix: Use ldap.EscapeFilter
Replace EscapeLDAPValue with ldap.EscapeFilter in both filter construction paths:
import "github.com/go-ldap/ldap/v3"
// Line 191 — UPN Domain path
bindDN = fmt.Sprintf("%s@%s", ldap.EscapeFilter(username), cfg.UPNDomain)
// Line 193 — User DN path
bindDN = fmt.Sprintf("%s=%s,%s", cfg.UserAttr, ldap.EscapeFilter(username), cfg.UserDN)
EscapeLDAPValue is still the correct choice for actual DN construction (where values are used as RDN components rather than filter values), but any value interpolated into an LDAP filter string must use ldap.EscapeFilter.
Audit: All Call Sites
Review all usages of EscapeLDAPValue across the codebase to ensure none are used in filter context:
grep -rn "EscapeLDAPValue" /root/cve-audit/openbao/
Defense-in-Depth
- Apply the principle of least privilege to LDAP service accounts used by OpenBao
- Use
UserFilterwith explicit attribute constraints to limit the search scope
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/openbao/openbao"
},
"ranges": [
{
"events": [
{
"introduced": "0.1.0"
},
{
"last_affected": "2.5.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/openbao/openbao"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260617104213-10b7825c714c"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55770"
],
"database_specific": {
"cwe_ids": [
"CWE-90"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T21:42:01Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "## 1. Description\n\n### Component\n\n`sdk/helper/ldaputil/client.go` \u2014 the shared LDAP utility library used by both the LDAP authentication backend and OpenLDAP secrets engine to construct LDAP search filters and bind DNs.\n\n### Root Cause\n\nThe LDAP utility contains a **function selection error** that causes incorrect escaping of user-controlled input in LDAP filter construction. Two lines construct the `bindDN` using `EscapeLDAPValue()`:\n\n```go\n// Line 191 \u2014 UPN Domain path\nbindDN = fmt.Sprintf(\"%s@%s\", EscapeLDAPValue(username), cfg.UPNDomain)\n\n// Line 193 \u2014 User DN path\nbindDN = fmt.Sprintf(\"%s=%s,%s\", cfg.UserAttr, EscapeLDAPValue(username), cfg.UserDN)\n```\n\nThe problem: `EscapeLDAPValue()` implements **RFC 4514** escaping, which is designed for Distinguished Name (DN) components. It only escapes characters meaningful in DNs: `+`, `,`, `;`, `\"`, `\\`, `\u003c`, `\u003e`, and leading/trailing spaces.\n\nLDAP **search filters** (RFC 4515) have a different set of special characters: `*`, `(`, `)`, `\\`, and NUL (`\\x00`). None of these are escaped by `EscapeLDAPValue()`. The correct function is `ldap.EscapeFilter()` from the `github.com/go-ldap/ldap/v3` package.\n\nThe irony: the same file uses `ldap.EscapeFilter()` correctly at lines 225-226 in `RenderUserSearchFilter()` for the `UserFilter` template path, but the `GetUserDN()` function at lines 191-193 uses the wrong escape function.\n\n### Exploitation Mechanics\n\n```\nUsername: alice)(objectClass=*\n\u2193 EscapeLDAPValue (no-op \u2014 no DN special chars)\nalice)(objectClass=*\n\u2193 fmt.Sprintf(\"(\u0026(objectClass=user)(sAMAccountName=%s))\", escapedUsername)\n(\u0026(objectClass=user)(sAMAccountName=alice)(objectClass=*))\n ^^ injection point\n```\n\nThe filter `(\u0026(objectClass=user)(sAMAccountName=alice)(objectClass=*))` is logically equivalent to:\n- `sAMAccountName=alice` AND `objectClass=user` AND `objectClass=*`\n\nSince all entries match `objectClass=*`, the filter matches **any user entry** where `sAMAccountName` is `alice`, effectively ignoring the `objectClass=user` constraint. By crafting more sophisticated injections (e.g., `alice)(|(sAMAccountName=admin`), the attacker can match arbitrary different user entries.\n\n### Preconditions\n\n- LDAP authentication backend must be configured\n- Directory must be Active Directory (UPNDomain path) or use UserDN/UserAttr binding\n- Attacker controls the `username` field at login time\n\n## 2. Proof of Concept\n\n```bash\n# Login with LDAP injection payload as username\ncurl -k -X POST \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\n \"username\": \"alice)(sAMAccountName=*\",\n \"password\": \"anything\"\n }\u0027 \\\n https://localhost:8200/v1/auth/ldap/login/admin\n\n# LDAP filter constructed:\n# (\u0026(objectClass=user)(sAMAccountName=alice)(sAMAccountName=*))\n# injection \u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500\u2500^\n# The filter matches the first user with objectClass=user\n# If the LDAP server returns admin\u0027s entry first, the token\n# is bound to the admin entity, inheriting all admin policies\n```\n\nThe LDAP search returns whichever entry the server ranks highest among results. In Active Directory with default sorting, this is often the oldest or alphabetically first user \u2014 potentially an administrative account.\n\n## 3. Impact\n\n| Impact | Detail |\n|--------|--------|\n| **Confidentiality** | Token bound to a different LDAP user (e.g., admin) grants access to all secrets and policies belonging to that entity |\n| **Integrity** | Ability to modify secrets, write policies, or configure backends as the impersonated user |\n| **Availability** | Low direct impact, but administrative access enables disabling or misconfiguring the entire OpenBao instance |\n\n**Likelihood: HIGH** \u2014 the escape function mismatch is a well-documented antipattern in OWASP LDAP Injection guidance. The attack is trivially exploitable with no special tooling beyond `curl`.\n\n### Why This Is High Severity\n\nThe LDAP auth backend is frequently used as a **primary authentication method** for enterprise OpenBao deployments. A successful LDAP injection against this backend can bypass the entire authentication chain, granting administrative access to the secrets store without needing to compromise an actual admin account.\n\n## 4. Remediation\n\n### Primary Fix: Use ldap.EscapeFilter\n\nReplace `EscapeLDAPValue` with `ldap.EscapeFilter` in both filter construction paths:\n\n```go\nimport \"github.com/go-ldap/ldap/v3\"\n\n// Line 191 \u2014 UPN Domain path\nbindDN = fmt.Sprintf(\"%s@%s\", ldap.EscapeFilter(username), cfg.UPNDomain)\n\n// Line 193 \u2014 User DN path\nbindDN = fmt.Sprintf(\"%s=%s,%s\", cfg.UserAttr, ldap.EscapeFilter(username), cfg.UserDN)\n```\n\n`EscapeLDAPValue` is still the correct choice for actual DN construction (where values are used as RDN components rather than filter values), but any value interpolated into an LDAP filter string must use `ldap.EscapeFilter`.\n\n### Audit: All Call Sites\n\nReview all usages of `EscapeLDAPValue` across the codebase to ensure none are used in filter context:\n\n```bash\ngrep -rn \"EscapeLDAPValue\" /root/cve-audit/openbao/\n```\n\n### Defense-in-Depth\n\n- Apply the principle of least privilege to LDAP service accounts used by OpenBao\n- Use `UserFilter` with explicit attribute constraints to limit the search scope",
"id": "GHSA-6mwx-4547-5vc9",
"modified": "2026-06-19T21:42:01Z",
"published": "2026-06-19T21:42:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openbao/openbao/security/advisories/GHSA-6mwx-4547-5vc9"
},
{
"type": "WEB",
"url": "https://github.com/openbao/openbao/pull/3306"
},
{
"type": "WEB",
"url": "https://github.com/openbao/openbao/commit/10b7825c714c1ef25b6c3c1c2cd6ecd8747c0659"
},
{
"type": "PACKAGE",
"url": "https://github.com/openbao/openbao"
},
{
"type": "WEB",
"url": "https://github.com/openbao/openbao/releases/tag/v2.5.5"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "OpenBao: LDAPi ldaputil (wrong escape func)"
}
GHSA-75V6-GF74-7FJW
Vulnerability from github – Published: 2026-01-30 15:31 – Updated: 2026-08-10 21:31An LDAP Injection vulnerability in WatchGuard Fireware OS may allow a remote unauthenticated attacker to retrieve sensitive information from a connected LDAP authentication server through an exposed authentication or management web interface. This vulnerability may also allow a remote attacker to authenticate as an LDAP user with a partial identifier if they additionally have that user's valid passphrase.This issue affects Fireware OS: from 12.0 through 12.11.6, from 12.5 through 12.5.15, from 2025.1 through 2026.0.
{
"affected": [],
"aliases": [
"CVE-2026-1498"
],
"database_specific": {
"cwe_ids": [
"CWE-90"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-30T13:15:54Z",
"severity": "HIGH"
},
"details": "An LDAP Injection vulnerability in WatchGuard Fireware OS may allow a remote unauthenticated attacker to retrieve sensitive information from a connected LDAP authentication server through an exposed authentication or management web interface. This vulnerability may also allow a remote attacker to authenticate as an LDAP user with a partial identifier if they additionally have that user\u0027s valid passphrase.This issue affects Fireware OS: from 12.0 through 12.11.6, from 12.5 through 12.5.15, from 2025.1 through 2026.0.",
"id": "GHSA-75v6-gf74-7fjw",
"modified": "2026-08-10T21:31:56Z",
"published": "2026-01-30T15:31:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-1498"
},
{
"type": "WEB",
"url": "https://psirt.watchguard.com/CVE-2026-1498"
},
{
"type": "WEB",
"url": "https://www.watchguard.com/wgrd-psirt/advisory/wgsa-2026-00001"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-78X9-6J67-9RJ6
Vulnerability from github – Published: 2025-01-14 12:31 – Updated: 2025-01-14 12:31A vulnerability has been identified in Mendix LDAP (All versions < V1.1.2). Affected versions of the module are vulnerable to LDAP injection. This could allow an unauthenticated remote attacker to bypass username verification.
{
"affected": [],
"aliases": [
"CVE-2024-56841"
],
"database_specific": {
"cwe_ids": [
"CWE-90"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-14T11:15:17Z",
"severity": "CRITICAL"
},
"details": "A vulnerability has been identified in Mendix LDAP (All versions \u003c V1.1.2). Affected versions of the module are vulnerable to LDAP injection. This could allow an unauthenticated remote attacker to bypass username verification.",
"id": "GHSA-78x9-6j67-9rj6",
"modified": "2025-01-14T12:31:50Z",
"published": "2025-01-14T12:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56841"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-314390.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-7M6R-FHH7-R47C
Vulnerability from github – Published: 2026-03-11 00:23 – Updated: 2026-03-11 05:47Impact
The LDAP authentication adapter is vulnerable to LDAP injection. User-supplied input (authData.id) is interpolated directly into LDAP Distinguished Names (DN) and group search filters without escaping special characters. This allows an attacker with valid LDAP credentials to manipulate the bind DN structure and to bypass group membership checks. This enables privilege escalation from any authenticated LDAP user to a member of any restricted group.
The vulnerability affects Parse Server deployments that use the LDAP authentication adapter with group-based access control.
Patches
The vulnerability is fixed by escaping user input before interpolation into DN strings (per RFC 4514) and LDAP filter strings (per RFC 4515).
Workarounds
There is no known workaround.
References
- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-7m6r-fhh7-r47c
- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.13
- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.26
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "parse-server"
},
"ranges": [
{
"events": [
{
"introduced": "9.0.0-alpha.1"
},
{
"fixed": "9.5.2-alpha.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "parse-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.6.26"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-31828"
],
"database_specific": {
"cwe_ids": [
"CWE-90"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-11T00:23:21Z",
"nvd_published_at": "2026-03-10T22:16:20Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nThe LDAP authentication adapter is vulnerable to LDAP injection. User-supplied input (`authData.id`) is interpolated directly into LDAP Distinguished Names (DN) and group search filters without escaping special characters. This allows an attacker with valid LDAP credentials to manipulate the bind DN structure and to bypass group membership checks. This enables privilege escalation from any authenticated LDAP user to a member of any restricted group.\n\nThe vulnerability affects Parse Server deployments that use the LDAP authentication adapter with group-based access control.\n\n### Patches\n\nThe vulnerability is fixed by escaping user input before interpolation into DN strings (per [RFC 4514](https://datatracker.ietf.org/doc/html/rfc4514#section-2.4)) and LDAP filter strings (per [RFC 4515](https://datatracker.ietf.org/doc/html/rfc4515#section-3)).\n\n### Workarounds\n\nThere is no known workaround.\n\n### References\n\n- GitHub security advisory: https://github.com/parse-community/parse-server/security/advisories/GHSA-7m6r-fhh7-r47c\n- Fix Parse Server 9: https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.13\n- Fix Parse Server 8: https://github.com/parse-community/parse-server/releases/tag/8.6.26",
"id": "GHSA-7m6r-fhh7-r47c",
"modified": "2026-03-11T05:47:03Z",
"published": "2026-03-11T00:23:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-7m6r-fhh7-r47c"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31828"
},
{
"type": "PACKAGE",
"url": "https://github.com/parse-community/parse-server"
},
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/releases/tag/8.6.26"
},
{
"type": "WEB",
"url": "https://github.com/parse-community/parse-server/releases/tag/9.5.2-alpha.13"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Parse Server vulnerable to LDAP injection via unsanitized user input in DN and group filter construction"
}
GHSA-82MG-X548-GQ3J
Vulnerability from github – Published: 2020-08-31 22:49 – Updated: 2021-09-23 19:58Versions 2.2.4 and earlier of ldapauth-fork are affected by an LDAP injection vulnerability. This allows an attacker to inject and run arbitrary LDAP commands via the username parameter.
Recommendation
ldapauth is not actively maintained, having not seen a publish since 2014. As a result, there is no patch available. Consider updating to use ldapauth-fork 2.3.3 or greater.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "ldapauth-fork"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.3.3"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c 2.2.4"
},
"package": {
"ecosystem": "npm",
"name": "ldapauth"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2015-7294"
],
"database_specific": {
"cwe_ids": [
"CWE-90"
],
"github_reviewed": true,
"github_reviewed_at": "2020-08-31T18:07:59Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "Versions 2.2.4 and earlier of `ldapauth-fork` are affected by an LDAP injection vulnerability. This allows an attacker to inject and run arbitrary LDAP commands via the username parameter.\n\n\n\n## Recommendation\n\nldapauth is not actively maintained, having not seen a publish since 2014. As a result, there is no patch available. Consider updating to use [ldapauth-fork](https://www.npmjs.com/package/ldapauth-fork) 2.3.3 or greater.",
"id": "GHSA-82mg-x548-gq3j",
"modified": "2021-09-23T19:58:02Z",
"published": "2020-08-31T22:49:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2015-7294"
},
{
"type": "WEB",
"url": "https://github.com/vesse/node-ldapauth-fork/issues/21"
},
{
"type": "WEB",
"url": "https://github.com/vesse/node-ldapauth-fork/commit/3feea43e243698bcaeffa904a7324f4d96df60e4"
},
{
"type": "PACKAGE",
"url": "https://github.com/vesse/node-ldapauth-fork"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/advisories/18"
},
{
"type": "WEB",
"url": "https://www.npmjs.com/advisories/19"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2015/09/18/4"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2015/09/18/8"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2015/09/21/2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "LDAP Injection in ldapauth"
}
GHSA-853R-VXG2-55R2
Vulnerability from github – Published: 2026-07-30 18:31 – Updated: 2026-07-31 18:32LDAP filter injection vulnerability in Apache Zeppelin. LdapRealm used RFC 4514 distinguished-name escaping when constructing LDAP search filters instead of RFC 4515 filter escaping, leaving special filter characters insufficiently escaped. This is an incomplete fix of CVE-2024-31867. This issue affects Apache Zeppelin versions 0.11.1, 0.11.2, and 0.12.0. Users are recommended to upgrade to version 0.12.1, which fixes this issue.
{
"affected": [],
"aliases": [
"CVE-2026-44617"
],
"database_specific": {
"cwe_ids": [
"CWE-90"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-30T16:17:12Z",
"severity": "MODERATE"
},
"details": "LDAP filter injection vulnerability in Apache Zeppelin. LdapRealm used RFC 4514 distinguished-name escaping when constructing LDAP search filters instead of RFC 4515 filter escaping, leaving special filter characters insufficiently escaped. \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0This is an incomplete fix of CVE-2024-31867. This issue affects Apache Zeppelin versions 0.11.1, 0.11.2, and 0.12.0. Users are recommended to upgrade to version 0.12.1, which fixes this issue.",
"id": "GHSA-853r-vxg2-55r2",
"modified": "2026-07-31T18:32:12Z",
"published": "2026-07-30T18:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44617"
},
{
"type": "WEB",
"url": "https://github.com/apache/zeppelin/pull/5226"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/s65t6n3s1v4j5b1w7zvv5w73ko69m1zv"
},
{
"type": "WEB",
"url": "https://www.cve.org/CVERecord?id=CVE-2024-31867"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8CJF-MHHJ-2C5P
Vulnerability from github – Published: 2026-07-30 18:31 – Updated: 2026-07-31 18:32LDAP injection vulnerability in Apache Zeppelin. ActiveDirectoryGroupRealm constructed LDAP search filters without escaping user-controlled input, allowing an authenticated attacker to inject LDAP filter syntax through the user-search endpoint and potentially expose directory information. The role-lookup path was also affected after successful LDAP authentication. This issue affects Apache Zeppelin versions 0.6.0 through 0.12.0. Users are recommended to upgrade to version 0.12.1, which fixes this issue.
{
"affected": [],
"aliases": [
"CVE-2026-44616"
],
"database_specific": {
"cwe_ids": [
"CWE-90"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-30T16:17:12Z",
"severity": "MODERATE"
},
"details": "LDAP injection vulnerability in Apache Zeppelin. ActiveDirectoryGroupRealm constructed LDAP search filters without escaping user-controlled input, allowing an authenticated attacker to inject LDAP filter syntax through the user-search endpoint \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0and potentially expose directory information. The role-lookup path was also affected after successful LDAP authentication. This issue affects Apache Zeppelin versions 0.6.0 through 0.12.0. Users are recommended to upgrade to version 0.12.1, which \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0fixes this issue.",
"id": "GHSA-8cjf-mhhj-2c5p",
"modified": "2026-07-31T18:32:12Z",
"published": "2026-07-30T18:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44616"
},
{
"type": "WEB",
"url": "https://github.com/apache/zeppelin/pull/5226"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/p6llqpvcszpg1wc8kx5ncfkdbms3g0rn"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/07/30/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-8HC5-RMGF-QX6P
Vulnerability from github – Published: 2023-11-29 21:33 – Updated: 2023-11-29 21:33A flaw was found in the Keycloak package. This flaw allows an attacker to benefit from an LDAP query and access existing usernames in the server.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-ldap-federation"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "23.0.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "org.keycloak:keycloak-services"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "23.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-2232"
],
"database_specific": {
"cwe_ids": [
"CWE-90"
],
"github_reviewed": true,
"github_reviewed_at": "2023-11-29T21:33:07Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "A flaw was found in the Keycloak package. This flaw allows an attacker to benefit from an LDAP query and access existing usernames in the server.",
"id": "GHSA-8hc5-rmgf-qx6p",
"modified": "2023-11-29T21:33:07Z",
"published": "2023-11-29T21:33:07Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/security/advisories/GHSA-8hc5-rmgf-qx6p"
},
{
"type": "WEB",
"url": "https://github.com/keycloak/keycloak/commit/4252e394cf725b16f7e4e19aa32b03fd3fe13fde"
},
{
"type": "PACKAGE",
"url": "https://github.com/keycloak/keycloak"
}
],
"schema_version": "1.4.0",
"severity": [],
"summary": "Keycloak vulnerable to LDAP Injection on UsernameForm Login"
}
Mitigation MIT-5
Strategy: Input Validation
- 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.
CAPEC-136: LDAP Injection
An attacker manipulates or crafts an LDAP query for the purpose of undermining the security of the target. Some applications use user input to create LDAP queries that are processed by an LDAP server. For example, a user might provide their username during authentication and the username might be inserted in an LDAP query during the authentication process. An attacker could use this input to inject additional commands into an LDAP query that could disclose sensitive information. For example, entering a * in the aforementioned query might return information about all users on the system. This attack is very similar to an SQL injection attack in that it manipulates a query to gather additional information or coerce a particular return value.