CVE-2026-55775 in OpenBao
Summary
by MITRE • 09/15/2026
OpenBao is an open source identity-based secrets management system. Prior to 2.5.5, OpenBao users granted capabilities on /sys/namespaces/root within a non-root namespace could exploit special handling of the literal root path in namespace canonicalization. The /sys/namespaces/* endpoint family can resolve its containing namespace through a path prefix or X-Vault-Namespace header. ACL checks occurred before root canonicalized to an empty path, causing /sys/namespaces/root to resolve to the system backend's containing namespace and allowing permitted lookups, deletion, locking, or custom metadata changes against that direct containing namespace. The root namespace and arbitrary unrelated namespaces are not affected, and available operations depend on the capabilities granted on the path and subpaths such as /api-lock. This issue is fixed in version 2.5.5.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/15/2026
OpenBao serves as an open-source identity-based secrets management system designed to secure access to sensitive data within enterprise environments. A critical security flaw was identified in versions prior to 2.5.5, specifically involving the handling of namespace canonicalization and Access Control List (ACL) evaluation logic. The vulnerability centers on a discrepancy between how paths are resolved for non-root namespaces versus the root system backend. Specifically, users who had been granted specific capabilities on the path /sys/namespaces/root within their own non-root namespace were able to exploit this inconsistency to perform unauthorized operations against the system's containing namespace. This issue stems from the special handling of the literal string root during path canonicalization processes, which failed to properly isolate the scope of administrative actions intended for user-defined namespaces.
The technical mechanism behind this vulnerability involves the resolution mechanisms used by the /sys/namespaces/* endpoint family. These endpoints are designed to resolve their containing namespace either through a provided path prefix or via an HTTP header such as X-Vault-Namespace. In the flawed implementation, when ACL checks were performed prior to canonicalizing root paths into an empty string representation, the system incorrectly mapped requests targeting /sys/namespaces/root within a non-root context back to the global system backend's namespace rather than restricting them to the user's local scope. Consequently, if a user possessed capabilities such as read or write permissions on this specific path segment within their own namespace, they could effectively bypass isolation boundaries and interact directly with the root namespace infrastructure.
The operational impact of this vulnerability allows for significant unauthorized actions against the system backend depending on the exact privileges granted to the affected user account. Permitted operations included lookups that could reveal sensitive configuration details, deletion of critical metadata or locks, modification of custom metadata associated with the root namespace, and manipulation of API locking mechanisms. These actions compromise the integrity and availability of the secrets management infrastructure by allowing a lower-privileged entity to alter system-level configurations intended only for global administrators. It is important to note that this vulnerability does not affect the actual root namespace itself in terms of direct exploitation from outside the context, nor does it impact arbitrary unrelated namespaces; the risk is strictly confined to users with specific ACL grants on /sys/namespaces/root within their own non-root namespace scope.
To mitigate this risk, organizations running OpenBao must immediately upgrade to version 2.5.5 or later, where the canonicalization logic has been corrected to ensure proper isolation between user namespaces and the system backend. In addition to upgrading, administrators should review existing ACL policies for any users who have been granted capabilities on /sys/namespaces/root within non-root namespaces. These permissions should be revoked unless absolutely necessary for specific operational requirements that do not involve interacting with the global namespace infrastructure. Adhering to the principle of least privilege is essential in this context, ensuring that access to system-level endpoints remains restricted to designated security administrators who require such elevated privileges for legitimate maintenance tasks.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management and CWE-732 Incorrect Permission Assignment for Critical Resource, as it involves the misconfiguration of access controls leading to unauthorized elevation of privilege or scope expansion. In terms of adversary behavior mapping under MITRE ATT&CK, this flaw facilitates techniques related to Defense Evasion by allowing attackers to manipulate system configurations without detection through standard audit trails that might not distinguish between legitimate administrative actions and those derived from namespace isolation bypasses. Furthermore, the ability to modify locks and metadata could support Persistence or Impact tactics if an attacker seeks to maintain access or disrupt service availability. Ensuring strict separation of duties and regular auditing of ACL assignments are critical steps in preventing exploitation of such architectural flaws in identity management systems.