Bug 2533973 (CVE-2026-55770)

Summary: CVE-2026-55770 github.com/openbao/openbao: OpenBao: Unauthorized access via LDAP search filter bypass
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedKeywords: Security
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in OpenBao. When the LDAP authentication backend is configured, an attacker can manipulate a username with special characters to alter the LDAP search query. This allows the attacker to select a different directory entry, potentially gaining unauthorized access to secrets, policies, or modification capabilities associated with another LDAP identity. This vulnerability stems from using an incorrect escaping function for LDAP search filters.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-09-15 15:58:16 UTC 
OpenBao is an open source identity-based secrets management system. Prior to 2.5.5, OpenBao used EscapeLDAPValue, an RFC 4514 distinguished-name escaping function, where RFC 4515 LDAP search-filter escaping was required in sdk/helper/ldaputil/client.go GetUserDN. With the LDAP authentication backend configured for an Active Directory UPNDomain path or UserDN and UserAttr binding, an attacker-controlled username containing filter metacharacters could alter the search predicate and select a different directory entry because EscapeLDAPValue does not neutralize the characters handled by ldap.EscapeFilter. A resulting token could be associated with another LDAP identity and gain access to secrets, policies, or modification capabilities assigned to that identity. This issue is fixed in version 2.5.5.