CVE-2026-115365 in OpenBaoinfo

Summary

by MITRE • 10/23/2026

OpenBao from 2.3.0 before 2.6.3 contains an incorrect authorization vulnerability in its ACL policy cache that allows tokens to reference policies from arbitrary namespaces using specially crafted policy names. Attackers holding such tokens can gain capabilities of cached policies in other namespaces, including the root namespace, to act across namespace boundaries.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 10/23/2026

The identified vulnerability within OpenBao versions 2.3.0 through 2.6.3 represents a critical failure in access control logic related to the handling of Access Control List policy caches. This flaw stems from an incorrect authorization mechanism that permits tokens to reference policies located in arbitrary namespaces via specially crafted policy names. In standard operational contexts, OpenBao utilizes namespace isolation to ensure that resources and permissions defined within one logical partition do not inadvertently affect or grant access to resources in another. However, the vulnerability bypasses this isolation by allowing a token authenticated under one namespace to invoke or leverage policies cached from a different namespace, including highly privileged configurations such as those found in the root namespace. This behavior fundamentally undermines the multi-tenancy model that OpenBao is designed to support, creating a pathway for privilege escalation across organizational boundaries within the vault infrastructure.

From a technical perspective, the core issue lies in how the system resolves policy references during authentication and authorization checks. When a token requests access to a resource, the system consults its ACL cache to determine if the necessary permissions are already established. The flaw allows an attacker who possesses a valid but limited token within a non-root namespace to manipulate the lookup process. By supplying crafted identifiers that point toward policies in other namespaces, the attacker can trick the caching mechanism into applying those external policies as if they were local to the current context. This effectively grants the user capabilities associated with the target policy, which may include administrative rights or access to sensitive secrets stored in the root namespace or other isolated partitions. The vulnerability exploits the trust relationship between token validation and policy resolution, turning a performance optimization feature into an attack vector for lateral movement within the vault environment.

The operational impact of this vulnerability is severe, as it enables unauthorized privilege escalation that can lead to full compromise of sensitive data stored in OpenBao. An attacker leveraging this flaw could potentially access secrets such as database credentials, API keys, or certificates intended only for specific services or teams operating in isolated namespaces. Furthermore, the ability to act across namespace boundaries means that a breach in a low-privilege environment can serve as a foothold for attacking high-value assets located elsewhere in the infrastructure. This violates the principle of least privilege and compromises data confidentiality and integrity on a systemic level. Organizations relying on OpenBao for strict separation of duties among different departments or customers face significant risk, as the isolation guarantees provided by namespaces are effectively nullified by this implementation error.

To mitigate this vulnerability, organizations must immediately upgrade their OpenBao instances to version 2.6.3 or later, where these authorization checks have been corrected to enforce proper namespace boundaries during policy resolution. Until an upgrade is feasible, administrators should review token policies and ensure that no tokens are granted permissions that could be exploited through cross-namespace references, although this manual mitigation is difficult due to the nature of the caching mechanism. It is also advisable to audit existing logs for any signs of anomalous access patterns involving unexpected policy resolutions or privilege escalations across namespaces. Implementing strict monitoring on authentication events and policy lookups can help detect exploitation attempts in real-time. Additionally, adhering to industry standards such as CWE-269 regarding improper authorization checks and considering the ATT&CK technique T1078 for valid accounts used laterally within a network environment provides a framework for assessing similar risks in other identity management systems.

Responsible

VulnCheck

Reservation

10/22/2026

Disclosure

10/23/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

very low

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!