OpenBao CVE-2026-55770

Three conditions must all be true: (1) the LDAP authentication backend must be enabled and configured in OpenBao (non-default; the backend is one of several auth methods); (2) the attacker must possess valid LDAP credentials for at least one directory account to successfully complete the initial bind step (PR:L - a standard low-privileged account is sufficient, no admin credential required); (3) the directory must use either Active Directory UPN Domain binding (UPNDomain set) or standard UserDN/UserAttr binding - both code paths pass through the vulnerable GetUserDN() function. The impersonation target depends on the LDAP server's result ordering in response to the injected filter (in Active Directory, commonly the alphabetically or chronologically first matching entry). Exploitation is limited by: the requirement for a pre-existing valid LDAP credential ruling out fully unauthenticated attacks; the LDAP server's result ordering behavior being outside the attacker's direct control (though sophisticated injections can narrow the match set); and the vulnerability being scoped to instances where LDAP is the configured auth method - deployments using only AppRole, JWT, PKI, or other backends are not affected.

The vendor-assigned CVSS 3.1 score of 6.8 (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N) accurately reflects the risk profile: network-accessible attack surface (AV:N), but requiring both a configured LDAP auth backend and a valid low-privileged LDAP credential (driving AC:H and PR:L). Confidentiality and Integrity impacts are both High because successful exploitation binds the attacker's OpenBao session token to an arbitrary directory user - potentially an administrator - granting read and write access to all secrets and policies associated with that entity. Availability impact is assessed None because the attack path does not directly disrupt service. No EPSS score was provided in the input data, so probability-of-exploitation inference must rely on other signals: the advisory includes a fully functional curl-based PoC requiring no special tooling, which significantly lowers exploitation barrier. The AC:H score is appropriate - LDAP must be the configured auth method, limiting the population of exposed instances - but within that population the attack is trivially executable. This is a genuine priority for enterprise OpenBao deployments using LDAP as a primary auth method; the 'high complexity' CVSS label should not be misread as 'hard to exploit in practice' by defenders where the preconditions are already met.

An attacker holding a valid but low-privileged LDAP account (e.g., a standard employee account) sends a POST request to /v1/auth/ldap/login/ with the username alice)(|(sAMAccountName=admin and their own legitimate password. The LDAP bind step succeeds using their real credentials, but the injected filter syntax causes OpenBao's directory search to return the admin user's entry rather than alice's. OpenBao then issues a session token scoped to the admin entity, granting the attacker full administrative access to the secrets store. A working PoC using a single curl command is published in the vendor advisory GHSA-6mwx-4547-5vc9.