CVE-2026-55770: 
Wolfi vulnerability analysis and mitigation

CVE-2026-55770 is an LDAP injection vulnerability in OpenBao's shared Go LDAP utility library (sdk/helper/ldaputil/client.go) caused by a function selection error that applies RFC 4514 DN escaping (EscapeLDAPValue()) instead of the required RFC 4515 filter escaping (ldap.EscapeFilter()) when constructing LDAP search filters and bind DNs. This affects all OpenBao versions >= 0.1.0 through 2.5.4, impacting both the LDAP authentication backend and the OpenLDAP secrets engine. The vulnerability was discovered and disclosed on June 17–19, 2026, with a fix merged the same day. It carries a CVSS v3.1 base score of 6.8 (Moderate) (GitHub Advisory, GitHub DB).

The root cause is a function selection error (CWE-90: LDAP Injection) in GetUserDN() within sdk/helper/ldaputil/client.go. The function uses EscapeLDAPValue() — which only escapes DN-special characters (+, ,, ;, ", \, <, >, and leading/trailing spaces per RFC 4514) — when constructing LDAP search filter strings that require RFC 4515 escaping of *, (, ), \, and NUL. Because filter-special characters pass through unescaped, an attacker who controls the username field can inject arbitrary LDAP filter clauses. Notably, the same file correctly uses ldap.EscapeFilter() in RenderUserSearchFilter(), making this an inconsistent application of the correct function. Exploitation requires only a crafted username string and a standard HTTP client such as curl (GitHub Advisory, Fix Commit).

A successful exploit allows an authenticated-but-low-privileged attacker to manipulate LDAP search filters so that the OpenBao token returned is bound to a different LDAP user — potentially an administrative account — granting full access to all secrets and policies belonging to that entity. This results in high confidentiality and integrity impact: the attacker can read arbitrary secrets, write policies, and reconfigure backends as the impersonated user. While direct availability impact is rated None, administrative access enables disabling or misconfiguring the entire OpenBao instance, effectively threatening the availability of dependent systems (GitHub Advisory).

A public proof-of-concept using only curl is included in the official security advisory, making exploitation trivial with no specialized tooling. The attack requires Low privileges (a valid LDAP login attempt) and High attack complexity due to dependency on LDAP server result ordering, but the advisory rates likelihood as HIGH given the well-documented OWASP LDAP injection antipattern. No in-the-wild exploitation, threat actor attribution, or CISA KEV listing has been reported as of the disclosure date. No EPSS score is currently available for this CVE (GitHub Advisory, GitHub DB).

1. Reconnaissance: Identify OpenBao instances (versions 0.1.0–2.5.4) with the LDAP authentication backend enabled, accessible via the API endpoint /v1/auth/ldap/login/<username>.
2. Understand target LDAP configuration: Determine whether the target uses UPNDomain (Active Directory UPN path) or UserDN/UserAttr binding, as both code paths are vulnerable.
3. Craft injection payload: Construct a username containing LDAP filter-special characters. For example, alice)(sAMAccountName=* injects an additional filter clause, or alice)(|(sAMAccountName=admin) to target a specific account.
4. Submit login request: Send a POST request to the OpenBao LDAP login endpoint with the crafted username:

curl -k -X POST \
  -H "Content-Type: application/json" \
  -d '{"username": "alice)(sAMAccountName=*", "password": "anything"}' \
  https://<openbao-host>:8200/v1/auth/ldap/login/admin

5. Observe filter manipulation: The constructed LDAP filter becomes (&(objectClass=user)(sAMAccountName=alice)(sAMAccountName=*)), matching the first user returned by the LDAP server — potentially an admin account.
6. Obtain elevated token: If the LDAP server returns an administrative entry first (common in Active Directory by default ordering), the OpenBao token is bound to that admin entity, inheriting all associated policies and secrets access (GitHub Advisory).

• Network: Unexpected HTTP POST requests to /v1/auth/ldap/login/<username> where the username field contains LDAP filter-special characters such as (, ), *, or \.
• Logs: OpenBao audit logs showing login attempts with usernames containing parentheses or asterisks; LDAP server logs showing search filters with injected clauses (e.g., (&(objectClass=user)(sAMAccountName=alice)(sAMAccountName=*))).
• Logs: OpenBao token issuance logs where the entity associated with a token does not match the username supplied in the login request.
• Behavioral: Tokens with unexpectedly broad policy assignments (e.g., admin-level) issued to accounts that should have limited access; unusual secret reads or policy modifications shortly after an LDAP login event.

Upgrade OpenBao to version 2.5.5 or later, which replaces EscapeLDAPValue() with ldap.EscapeFilter() in both the GetUserDN() function (sdk/helper/ldaputil/client.go) and the OpenLDAP secrets engine client (builtin/logical/openldap/client.go) (v2.5.5 Release, Fix Commit). As a defense-in-depth measure prior to patching, apply the principle of least privilege to LDAP service accounts used by OpenBao and configure UserFilter with explicit attribute constraints to limit search scope. Audit all usages of EscapeLDAPValue in any custom or forked code to ensure none appear in filter construction contexts (GitHub Advisory).

The fix was authored and merged by OpenBao maintainer Alexander Scheel (cipherboy) on June 17, 2026, the same day the issue was identified, demonstrating a rapid response from the project (PR #3306). The vulnerability was reported by security researcher alcls01111. The NixOS community promptly updated the OpenBao package from 2.5.4 to 2.5.5 in response (GitHub Advisory). German Linux security outlet pro-linux.de covered the multi-vulnerability OpenBao release, and Tenable published a Nessus detection plugin (IDs 323124 and 323130) shortly after disclosure.