OpenBao EUVD-2026-108290

Requires an authenticated attacker holding an OpenBao token that can be attached with specially crafted policy names (PR:H), on OpenBao versions 2.3.0 through 2.6.2. The decisive precondition, stated by the advisory, is that the referenced policies must be present in OpenBao's in-memory LRU policy cache both at token-creation time and at token-use time - an attacker-influenced but not fully controlled timing/caching condition that limits reliability (reflected as AT:P). A further limitation: when a token references another namespace's 'root' policy, those capabilities are granted only within the token's own namespace rather than the target's. Exposure is meaningfully higher in multi-tenant deployments that rely on namespace isolation; single-namespace deployments have limited practical exposure. The complete fix is upgrading to 2.6.3 or 2.7.0; the only stated workaround is setting disable_cache=true, which disables most caching and significantly degrades performance.

This is a genuine privilege-escalation concern for multi-tenant OpenBao deployments, but not a drop-everything emergency. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:H/VA:H) scores 7.5 (High) and, because it contains PR:H, confirms the attacker must be authenticated - specifically a holder of a valid OpenBao token. The AT:P (attack requirement) metric reflects a real limiter stated in the advisory: the referenced policies must be resident in OpenBao's in-memory LRU policy cache both at token-creation time and at token-use time, a condition the attacker does not fully control. There is no CISA KEV listing, no EPSS score was provided in the input, and no public exploit or PoC reference is present - so exploitation signals are weak and nothing indicates active, widespread use. The vuln.today decision label is 'this_week', consistent with a serious authorization flaw that is gated by authentication and a timing/caching precondition rather than remotely trivial. The impact ceiling is high (crossing namespace boundaries to gain capabilities in other namespaces, including root), so for organizations running OpenBao with namespace-based tenant isolation this warrants prompt patching; for single-namespace or non-tenant deployments the practical exposure is lower. One signal to verify: the input Tags label this 'Authentication Bypass', but the CWE (863) and the description describe incorrect authorization/privilege escalation across namespaces, not a bypass of authentication - the attacker already needs a token.

An attacker who already holds a valid, lower-privilege OpenBao token in one namespace obtains or creates a token whose attached policy names are specially crafted to reference policies cached in other namespaces, including root. When those referenced policies are present in the server's LRU policy cache at both creation and use time, the token inherits their capabilities in the respective namespaces, letting the attacker act across namespace boundaries. No public exploit was identified at the time of analysis.