Skip to main content

OpenBao CVE-2026-55775

LOW
Improper Authorization (CWE-285)
2026-06-19 https://github.com/openbao/openbao GHSA-mwr2-wmgp-crj6

Severity by source

vuln.today AI
9.9 CRITICAL

Low-privilege authenticated token required (PR:L); scope changes from child to parent namespace (S:C); namespace deletion yields high integrity and availability impact.

3.1 AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:H/A:H
4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:H/SC:N/SI:N/SA:H

Lifecycle Timeline

2
Source Code Evidence Fetched
Jun 19, 2026 - 23:48 vuln.today
Analysis Generated
Jun 19, 2026 - 23:48 vuln.today

DescriptionCVE.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:

sh
bao server -dev

Create a namespace:

sh
bao namespace create victim

This will be the namespace we gain unauthorized management of.

Create a policy that allows management of namespaces, _inside_ of the victim namespace.

sh
bao policy write -namespace=victim namespace-management - <<EOF
path "sys/namespaces/*" {
	capabilities = ["read", "update", "patch", "delete"]
}
EOF

Then create a token with above policy attached:

sh
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:

sh
bao namespace delete -namespace=victim root

AnalysisAI

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.

CVE-2026-45321 CRITICAL POC
9.6 May 12

Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio

CVE-2026-34976 CRITICAL POC
10.0 Apr 02

Unauthenticated remote attackers can trigger complete database overwrites, server-side file reads, and SSRF attacks agai

CVE-2021-30476 CRITICAL POC
9.8 Apr 22

HashiCorp Terraform’s Vault Provider (terraform-provider-vault) did not correctly configure GCE-type bound labels for Va

CVE-2019-7442 CRITICAL POC
9.8 May 08

An XML external entity (XXE) vulnerability in the Password Vault Web Access (PVWA) of CyberArk Enterprise Password Vault

CVE-2018-20371 CRITICAL POC
9.8 Dec 23

PhotoRange Photo Vault 1.2 appends the password to the URI for authorization, which makes it easier for remote attackers

CVE-2018-9843 CRITICAL POC
9.8 Apr 12

The REST API in CyberArk Password Vault Web Access before 9.9.5 and 10.x before 10.1 allows remote attackers to execute

CVE-2026-54725 CRITICAL POC
9.6 Jul 31

Server-side request forgery in bank-vaults vault-secrets-webhook (<= 1.22.2) lets a low-privileged tenant with ConfigMap

CVE-2026-60104 CRITICAL POC
9.3 Jul 08

Account takeover in self-hosted Bitwarden Server before 2026.6.0 lets a low-privileged organization member steal any oth

CVE-2021-43837 CRITICAL POC
9.1 Dec 16

vault-cli is a configurable command-line interface tool (and python library) to interact with Hashicorp Vault. Rated cri

CVE-2020-16272 CRITICAL POC
9.1 Aug 03

The SRP-6a implementation in Kee Vault KeePassRPC before 1.12.0 is missing validation for a client-provided parameter, w

CVE-2020-16271 CRITICAL POC
9.1 Aug 03

The SRP-6a implementation in Kee Vault KeePassRPC before 1.12.0 generates insufficiently random numbers, which allows re

CVE-2026-53727 HIGH POC
8.9 Jul 09

Server-side request forgery in the Ruby css_parser gem (< 3.0.0) lets a remote unauthenticated attacker force the parsin

Share

CVE-2026-55775 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy