OpenBao EUVD-2026-85519

Requires a specific ACL policy layout: a capabilities = ["deny"] grant on a trailing-wildcard path (e.g. secrets/metadata/restricted/*) combined with a broader list (or scan) grant on a parent wildcard (e.g. secrets/metadata/*). Only LIST and SCAN operations bypass the deny - read/write/delete/other operations were unaffected. The attacker must be an authenticated OpenBao client holding a token bound to the broader list-granting policy; there is no unauthenticated path. Limiting factors: the flaw only leaks metadata path/key names via listing (not secret values), the vulnerable policy layering must actually exist in the deployment, and the deployment must run OpenBao prior to v2.6.0.

This is a genuine but low-priority access-control flaw. Severity signals are sparse: the vendor (OpenBao/GHSA-xp3c-3jw3-4vcr) assigned CVSS N/A, there is no EPSS score, no CISA KEV listing, and no public exploit - status is no public exploit identified at time of analysis. The impact is narrowly scoped: only LIST and SCAN operations are affected, and only when an operator has layered a more-specific deny wildcard beneath a broader list grant; all other operation types (read/write/delete) correctly honored the deny. Because LIST/SCAN in OpenBao return key names/path segments rather than secret values, the realistic damage is enumeration of restricted metadata paths that should have been hidden - a confidentiality-only leak, not secret exfiltration. No CVSS vector was published, so authentication requirements are inferred from mechanics rather than confirmed: exploitation requires an authenticated caller holding a token bound to the broader list-granting policy, so this is not remotely-unauthenticated. Net: a real correctness/authorization bug worth patching, but low real-world urgency given the narrow operation scope, information-only impact, required authentication, and the specific policy-layering configuration needed to trigger it.

An operator writes a policy allowing list on secrets/metadata/* but explicitly denys the more specific secrets/metadata/restricted/*, expecting the deny to win. An authenticated user holding that policy issues a LIST (or SCAN) against the restricted subtree; OpenBao skips the stricter deny and returns the child key names, disclosing the existence and structure of restricted metadata paths. No public exploit code exists, but the fix commit ships a test that deterministically demonstrates the bypass.