GHSA-mwr2-wmgp-crj6
Fix: openbao/openbao@d3c1cc6GHSA-mwr2-wmgp-crj6 is a CWE-285 vulnerability in github.com/openbao/openbao. O3 Security confirms whether GHSA-mwr2-wmgp-crj6 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
OpenBao's System Backend allows Unauthorized Management of the containing Namespace
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-mwr2-wmgp-crj6.
Real-World Exposure
github.com/openbao/openbao🐹github.com/openbao/openbaoReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
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 -dev
Create a namespace:
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.
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:
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 root
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/openbao/openbao | all versions | 0.0.0-20260617103935-d3c1cc64b1ae |
| 🐹Go | github.com/openbao/openbao | ≥ 0.1.0 | No fix |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/openbao/openbao. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/openbao/openbao to 0.0.0-20260617103935-d3c1cc64b1ae or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mwr2-wmgp-crj6 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-mwr2-wmgp-crj6 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-mwr2-wmgp-crj6. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-mwr2-wmgp-crj6 in your dependencies?
O3 detects GHSA-mwr2-wmgp-crj6 across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.