OpenBao CVE-2026-55775
LOWSeverity by source
Low-privilege authenticated token required (PR:L); scope changes from child to parent namespace (S:C); namespace deletion yields high integrity and availability impact.
Lifecycle Timeline
2DescriptionCVE.org
Summary
A user that is granted namespace management (/sys/namespaces) capabilities within a non-root namespace ("the victim namespace") can abuse special handling of the literal path "root" in namespace path canonicalization to manage the victim namespace itself.
Details
Several endpoints under /sys/namespaces/* accept a namespace path segment that is canonicalized and then appended to the path of the sys mount's containing namespace (set via path prefix or X-Vault-Namespace header) to determine the absolute path of the namespace to operate on.
Given the special namespace path "root" canonicalizes to en empty path (""), when passed as /sys/namespaces/root, the resulting absolute namespace path remains equal to the sys mount's containing namespace. Given ACLs are evaluated before namespace path canonicalization, this allows users with capabilities on /sys/namespaces/root within any given namespace to operate on the namespace itself instead.
Impact
Users that were granted the required capabilities can abuse this vulnerability to:
- Look up
- Delete
- Lock
- Patch custom metadata
against the namespace containing the system backend they can manage sys/namespaces/root in. The exact range of operations that can be performed depends on the specific capabilities granted on said path and any sub-paths such as /api-lock.
Notably, the root namespace is immutable and cannot be modified, deleted or locked, and is thus unaffected. Also note that users can only abuse this vulnerability to operate on the direct parent or "containing" namespace relative to their capabilities, not arbitrary namespaces.
Patch
This will be fixed in OpenBao v2.5.5.
PoC
Start a development server:
bao server -devCreate a namespace:
bao namespace create victimThis will be the namespace we gain unauthorized management of.
Create a policy that allows management of namespaces, _inside_ of the victim namespace.
bao policy write -namespace=victim namespace-management - <<EOF
path "sys/namespaces/*" {
capabilities = ["read", "update", "patch", "delete"]
}
EOFThen create a token with above policy attached:
export BAO_TOKEN=$(bao token create -namespace=victim -policy=namespace-management -field=token)Operate on the victim's namespace using the token, for example by outright deleting it:
bao namespace delete -namespace=victim rootAnalysisAI
Namespace path canonicalization in OpenBao (versions 0.1.0 through 2.5.4) allows an authenticated token-holder with delegated namespace management capabilities inside a non-root namespace to operate on the containing (parent) namespace itself, rather than only its children. By passing the reserved literal string 'root' as the target namespace path to any /sys/namespaces/* endpoint, the path resolves to the containing namespace after canonicalization - because ACL evaluation occurs before that resolution, the access check passes on the child-scoped policy while the actual operation targets the parent. An attacker exploiting this can look up, delete, lock, or patch custom metadata on the containing namespace, with namespace deletion representing the most severe outcome: destroying all secrets, leases, and policies within it. A working public PoC is published in the GitHub Security Advisory (GHSA-mwr2-wmgp-crj6); no confirmed active exploitation in CISA KEV at time of analysis.
Technical ContextAI
OpenBao (Go module github.com/openbao/openbao, CPE pkg:go/github.com_openbao_openbao) is an open-source secrets management platform forked from HashiCorp Vault. It implements a hierarchical namespace model where the /sys/namespaces/* API endpoints accept a namespace path segment that is canonicalized by the internal namespace.Canonicalize() function before being appended to the containing namespace's path to compute the absolute target namespace. Prior to fix commit d3c1cc64b1ae, the Canonicalize() function mapped both '.' and the literal string 'root' to an empty path (''), a design choice that treated 'root' as a path alias for 'no child.' Because Vault-derived ACL evaluation occurs before canonicalization, a policy granting capabilities on sys/namespaces/root within namespace X is evaluated and approved against the literal string 'root', but the subsequent path resolution produces an empty suffix - leaving the absolute target equal to namespace X itself. The root cause is CWE-285 (Improper Authorization): the authorization boundary and the resource resolution logic operate on different representations of the same input, creating a logic gap equivalent to a time-of-check/time-of-use inconsistency. The patch introduces a new ParseName() validation function that rejects empty resolved names and reserved identifiers before they reach the append stage, and removes 'root' from the special-case map in Canonicalize(), restoring the invariant that 'root' is a plain reserved name rather than a path alias.
RemediationAI
Upgrade to OpenBao v2.5.5 or later (https://github.com/openbao/openbao/releases/tag/v2.5.5), which incorporates fix commit d3c1cc64b1ae introducing the ParseName() validation function and removing 'root' from the canonicalization alias map. If an immediate upgrade is not feasible, the most effective compensating control is to audit and narrow all namespace management policies: replace wildcard grants on sys/namespaces/* with policies scoped to explicit named child namespaces (e.g., sys/namespaces/child-a), which eliminates the ability to target the reserved 'root' path entirely. Additionally, revoke any tokens or service accounts bound to policies that include sys/namespaces/root as a capability path. Note that restricting to explicit child names does reduce administrative flexibility and may require policy updates if new child namespaces are created. The root namespace cannot be targeted regardless of policy, so root-namespace administrators are not exposed. Full advisory and patch details: https://github.com/openbao/openbao/security/advisories/GHSA-mwr2-wmgp-crj6.
Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio
Unauthenticated remote attackers can trigger complete database overwrites, server-side file reads, and SSRF attacks agai
HashiCorp Terraform’s Vault Provider (terraform-provider-vault) did not correctly configure GCE-type bound labels for Va
An XML external entity (XXE) vulnerability in the Password Vault Web Access (PVWA) of CyberArk Enterprise Password Vault
PhotoRange Photo Vault 1.2 appends the password to the URI for authorization, which makes it easier for remote attackers
The REST API in CyberArk Password Vault Web Access before 9.9.5 and 10.x before 10.1 allows remote attackers to execute
Server-side request forgery in bank-vaults vault-secrets-webhook (<= 1.22.2) lets a low-privileged tenant with ConfigMap
Account takeover in self-hosted Bitwarden Server before 2026.6.0 lets a low-privileged organization member steal any oth
vault-cli is a configurable command-line interface tool (and python library) to interact with Hashicorp Vault. Rated cri
The SRP-6a implementation in Kee Vault KeePassRPC before 1.12.0 is missing validation for a client-provided parameter, w
The SRP-6a implementation in Kee Vault KeePassRPC before 1.12.0 generates insufficiently random numbers, which allows re
Server-side request forgery in the Ruby css_parser gem (< 3.0.0) lets a remote unauthenticated attacker force the parsin
Same weakness CWE-285 – Improper Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-mwr2-wmgp-crj6