CVE-2026-115366 in OpenBao
Summary
by MITRE • 10/22/2026
OpenBao from 2.3.0 before 2.6.3 contains an improper authorization vulnerability that allows privileged child-namespace tokens to modify plugin registrations because /v1/sys/plugins/catalog/* is not restricted to the root namespace. Attackers can remove existing registrations, create invalid ones, or register installed plugins through a child namespace's sys/ mount, causing denial of service.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in OpenBao versions ranging from 2.3.0 up to but excluding 2.6.3 represents a critical failure in access control logic within the plugin catalog subsystem. This flaw stems from an improper authorization mechanism where the API endpoint responsible for managing plugin registrations, specifically /v1/sys/plugins/catalog/*, fails to enforce namespace boundaries correctly. In OpenBao’s multi-tenant architecture, namespaces are designed to provide logical isolation of resources and policies between different tenants or organizational units. However, this vulnerability allows tokens associated with privileged child namespaces to execute administrative actions that should be strictly reserved for the root namespace. This misconfiguration effectively bypasses the intended security perimeter, granting lower-level entities capabilities that compromise the integrity of the entire system's plugin management infrastructure.
From a technical perspective, the core issue lies in how the authentication and authorization middleware processes requests directed at the sys/plugins/catalog endpoints. Instead of validating whether the requesting token possesses privileges within the root namespace or restricting such operations to root-only contexts, the system erroneously accepts these commands from child namespaces with elevated permissions. This allows an attacker who has obtained a privileged token for any non-root namespace to interact directly with the global plugin catalog. The lack of proper scoping means that actions intended to be globally exclusive are treated as valid within the context of a subordinate tenant, leading to unauthorized modifications of system-wide configurations.
The operational impact of this vulnerability is severe and multifaceted. An attacker can exploit this flaw to remove existing plugin registrations, which disrupts services relying on those plugins and leads to immediate denial of service conditions for dependent applications. Furthermore, the ability to create invalid or maliciously crafted plugin registrations allows an adversary to corrupt the system state, potentially causing crashes during subsequent restarts or initialization phases. By registering installed plugins through a child namespace’s sys mount, attackers can introduce compromised code into the global environment if those plugins are subsequently loaded by privileged processes. This not only destabilizes the OpenBao instance but also poses significant risks for data confidentiality and integrity across all namespaces hosted on that instance.
This vulnerability aligns with CWE-269, which classifies Improper Privilege Management, specifically highlighting cases where an actor is able to elevate privileges or perform actions outside their intended scope due to flawed access control logic. In terms of the MITRE ATT&CK framework, this behavior corresponds to techniques involving privilege escalation and defense evasion, as it allows lateral movement within the system architecture by exploiting trust boundaries between namespaces. The ability to modify global configurations from a restricted context undermines the fundamental isolation guarantees provided by multi-tenancy models.
To mitigate this risk, organizations running OpenBao must upgrade immediately to version 2.6.3 or later, where these authorization checks have been corrected to properly restrict plugin catalog modifications to root namespace tokens only. Until an upgrade is feasible, administrators should implement strict network-level access controls to limit exposure of the sys endpoints and closely monitor audit logs for any unusual activity related to plugin registration changes originating from non-root namespaces. Additionally, enforcing least-privilege principles by ensuring that child namespace tokens do not hold unnecessary elevated permissions can reduce the attack surface available to potential adversaries exploiting this flaw.