6.8
Medium
github.com/openbao/openbao

CVE-2026-55770

CVE-2026-55770 is a medium-severity security vulnerability in github.com/openbao/openbao (go), affecting versions >= 0.1.0, <= 2.5.4. It is fixed in 0.0.0-20260617104213-10b7825c714c.

Key facts
CVSS score
6.8
Medium
Attack vector
Network
Issuing authority
GitHub Advisory Database
Affected package
github.com/openbao/openbao
Fixed in
0.0.0-20260617104213-10b7825c714c
Disclosed
2026

Summary

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(): 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 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 username field at login time Proof of Concept 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. 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. Remediation Primary Fix: Use ldap.EscapeFilter Replace EscapeLDAPValue with ldap.EscapeFilter in both filter construction paths: 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: Defense-in-Depth Apply the principle of least privilege to LDAP service accounts used by OpenBao Use UserFilter with explicit attribute constraints to limit the search scope

Impact

Severity and exposure

CVE-2026-55770 has a CVSS score of 6.8 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment.

A fixed version is available (0.0.0-20260617104213-10b7825c714c). Upgrading removes the vulnerable code path.

Affected versions

go

  • github.com/openbao/openbao (>= 0.1.0, <= 2.5.4)
  • github.com/openbao/openbao (< 0.0.0-20260617104213-10b7825c714c)

Security releases

  • github.com/openbao/openbao → 0.0.0-20260617104213-10b7825c714c (go)
Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter instead of chasing every advisory.

Kodem's runtime-powered SCA identifies whether CVE-2026-55770 is reachable in your applications. Explore open-source security for your team.

See if CVE-2026-55770 is reachable in your applications. Get a demo

Remediation advice

Upgrade github.com/openbao/openbao to 0.0.0-20260617104213-10b7825c714c or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently asked questions about CVE-2026-55770

What is CVE-2026-55770?

CVE-2026-55770 is a medium-severity security vulnerability in github.com/openbao/openbao (go), affecting versions >= 0.1.0, <= 2.5.4. It is fixed in 0.0.0-20260617104213-10b7825c714c.

How severe is CVE-2026-55770?

CVE-2026-55770 has a CVSS score of 6.8 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.

Which versions of github.com/openbao/openbao are affected by CVE-2026-55770?

github.com/openbao/openbao (go) versions >= 0.1.0, <= 2.5.4 is affected.

Is there a fix for CVE-2026-55770?

Yes. CVE-2026-55770 is fixed in 0.0.0-20260617104213-10b7825c714c. Upgrade to this version or later.

Is CVE-2026-55770 exploitable, and should I be worried?

Whether CVE-2026-55770 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo

What actually determines whether CVE-2026-55770 is exploitable, and how bad it is?

Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.

How do I fix CVE-2026-55770?

Upgrade github.com/openbao/openbao to 0.0.0-20260617104213-10b7825c714c or later.

Stop the waste.
Protect your environment with Kodem.