CVE-2026-115365: 
Wolfi vulnerability analysis and mitigation

CVE-2026-115365 is an incorrect authorization vulnerability in OpenBao's ACL policy cache that allows tokens with specially crafted policy names to reference and gain capabilities of policies from arbitrary namespaces, including the root namespace. It affects OpenBao versions 2.3.0 through 2.6.2 (i.e., before 2.6.3) and is noted as originating from a flaw also present in HashiCorp Vault. The vulnerability was published on October 22, 2026, with the GitHub Security Advisory (GHSA-mjch-vcw3-hhmf) published September 23, 2026. It carries a CVSS v3.1 base score of 6.6 (High) and a CVSS v4.0 base score of 7.5 (High) (GitHub Advisory, VulnCheck).

The root cause is classified as CWE-863 (Incorrect Authorization) and CWE-24 (Path Traversal), where OpenBao's in-memory LRU ACL policy cache fails to properly validate namespace boundaries when resolving policy names (GitHub Advisory). An attacker holding a token can craft a policy name that traverses namespace boundaries, causing the cache to resolve and apply policies belonging to other namespaces — including the root namespace — to the attacker's token. Two key preconditions apply: the referenced policies must be present in OpenBao's in-memory LRU policy cache at both token creation time and token use time, and the attacker must already hold a token with elevated (high) privileges. When referencing the root policy of another namespace, its capabilities are granted within the token's own namespace rather than the target namespace (GitHub Advisory).

Successful exploitation allows an attacker to escalate their capabilities to those of policies in other namespaces, including the root namespace, enabling unauthorized cross-namespace actions within OpenBao. This can result in high confidentiality, integrity, and availability impacts on the vulnerable system, including unauthorized access to secrets, modification of policies or data, and potential disruption of service (GitHub Advisory, VulnCheck). The ability to act as the root namespace effectively breaks the multi-tenancy isolation model of OpenBao, posing significant risk in environments where namespace separation is a security boundary.

No public proof-of-concept exploit code or evidence of in-the-wild exploitation has been reported as of the publication date (GitHub Advisory). The EPSS score is reported at 0.0, indicating a currently low probability of exploitation in the near term (VulnCheck). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires an attacker to already possess a high-privileged token and relies on specific cache state conditions, limiting opportunistic exploitation.

1. Obtain a high-privileged token: Acquire a token within an OpenBao namespace that has sufficient privileges to create or reference policies (high-privilege access is required as a precondition).
2. Identify target namespace policies: Determine the names of policies in other namespaces (e.g., the root namespace) that are likely cached in OpenBao's in-memory LRU policy cache.
3. Craft a malicious policy name: Construct a specially crafted policy name that traverses namespace boundaries (exploiting the path traversal aspect, CWE-24) to reference a policy in the target namespace.
4. Attach crafted policy to a token: At token creation time, attach the crafted policy name to a token, ensuring the target policy is present in the LRU cache at this moment.
5. Use the token to act across namespaces: Present the token for authentication; OpenBao's ACL policy cache incorrectly resolves the crafted policy name to the target namespace's policy, granting the token those capabilities and allowing cross-namespace actions including root-level operations (GitHub Advisory).

• Logs: OpenBao audit logs showing token operations with policy names containing unusual path-like strings or namespace separators (e.g., ../, //, or unexpected namespace prefixes) that do not correspond to legitimate policies in the token's own namespace.
• Logs: Audit log entries reflecting access to secrets or capabilities in namespaces that the token's assigned namespace should not have access to, particularly the root namespace.
• Network: API calls to OpenBao endpoints (e.g., /v1/auth/token/create, /v1/sys/policies/acl/) from unexpected sources or with anomalous policy name parameters.
• Behavioral: Tokens exhibiting capabilities beyond what their namespace policies should permit, especially root-level operations originating from non-root namespace tokens (GitHub Advisory).

OpenBao has released patched versions v2.6.3 and v2.7.0, which address this vulnerability; upgrading to either version is the recommended remediation (GitHub Advisory). As a temporary workaround for environments that cannot immediately upgrade, setting disable_cache = true in the OpenBao server configuration will disable the ACL policy cache and prevent exploitation, though this will significantly degrade performance (GitHub Advisory). Organizations should prioritize upgrading to v2.6.3 or v2.7.0 and review audit logs for any signs of cross-namespace policy abuse.

The vulnerability was credited to reporter Michael-JRead and remediation developer satoqz in the official GitHub Security Advisory (GitHub Advisory). The advisory notes that this vulnerability is original to HashiCorp Vault, suggesting a shared codebase lineage issue. No significant broader media coverage or notable social media reactions have been identified at this time.