OpenBao ACL wildcard authorization bypass permits unauthorized LIST access

OpenBao is an open source identity-based secrets management system. Prior to 2.6.0, OpenBao's vault/policy/acl.go could evaluate a broader wildcard ACL grant before more-specific trailing-wildcard ACL paths with capabilities = ["deny"] for a LIST operation. When a parent path permitted LIST and a child path was denied, the trailing-slash lookup could therefore allow listing the denied path. Other operation types are outside the repository advisory's affected scope. This issue is fixed in version 2.6.0.

• OpenBao before 2.6.0: affected when an ACL permits LIST on a parent path and applies capabilities = ["deny"] to a more-specific child trailing-wildcard path.
• OpenBao 2.6.0: confirmed by the advisory and release notes as the patched version.

The available evidence does not provide a separate matrix for other parallel release branches. Do not infer the status of an unlisted branch solely from the confirmation that 2.6.0 is patched.

OpenBao evaluates ACL policy logic in vault/policy/acl.go. Before the fix, a broader wildcard grant for LIST on a parent path could be evaluated before a more-specific trailing-wildcard rule with capabilities = ["deny"] on a child path. When the request used the trailing-slash lookup form, the broader grant could therefore permit listing a path that the policy intended to deny. The required condition is a policy combination with LIST allowed on the parent and a more-specific deny on the child; the caller also needs an authenticated identity able to submit the request. The pull request changes the evaluation logic so the more-specific rule is honored in this case. The exact backend and returned data depend on the deployed policy and secret engine.

The flaw is remotely reachable through the OpenBao service by an authenticated low-privilege user, without interaction from another user. Exploitation requires the specific ACL construction in which a parent path permits LIST while a child trailing-wildcard path is denied. The public advisory does not document concrete exploitation steps, a specific endpoint, or a payload. The supplied record marks a public exploit as false and does not identify a campaign or victim; that does not prove the flaw has never been exploited.

• The technical result is an authorization check that fails to honor a more-specific deny, allowing a LIST operation on a path blocked by policy.
• The attacker still needs an authenticated identity; the flaw does not by itself grant access to an unauthenticated user.
• The affected scope is centered on LIST and the wildcard ACL arrangement described above. The advisory places other operation types outside its affected scope.
• Possible consequences include disclosure of path names, metadata, or, for some configurations noted by the maintainers, secret values. The actual data exposure depends on the policy, secret engine, and path.
• The record does not establish an integrity or availability impact for OpenBao.

The flaw weakens the access boundaries that an organization establishes through OpenBao ACL policies.

• An authenticated user with limited privileges may discover paths or metadata that should be hidden.
• For some path configurations, the maintainers note that bypassing the check can expose secret values, including cases involving KVv2; the evidence does not establish secret-content exposure for every deployment.
• The advisory does not identify impact to operations other than LIST, so this record does not support claims of write, delete, or service-disruption capability.
• Disclosure of namespace structure or secret names can still provide useful information for subsequent unauthorized access attempts.

1. Upgrade OpenBao to exactly 2.6.0, the confirmed patched release for this issue.
2. Before and after the upgrade, inventory ACL policies that combine a parent LIST grant with a child trailing-wildcard deny, then test sensitive paths in a staging environment.
3. If an immediate upgrade is not possible, reduce network exposure for identities that can reach the service and review policies that rely on a specific deny overriding a broader parent LIST grant. This is a temporary compensating measure, not a substitute for the patch.
4. For any release branch not named by the advisory, confirm the corresponding vendor guidance before treating that branch as fixed.

1. Inventory OpenBao instances and determine the running version, with priority for deployments below 2.6.0.
2. Review ACL policies for a broad wildcard or parent LIST grant paired with capabilities = ["deny"] on a more-specific child path with a trailing wildcard.
3. In a test environment, exercise representative policy pairs with an authenticated identity and confirm that LIST requests to the denied child path fail after the update.
4. As a precaution, review audit logs for LIST requests against sensitive paths. The available evidence does not establish a dedicated log event or IOC for this issue, and absence of matching logs does not prove that a deployment is safe.