OpenBao's System Backend allows Unauthorized Management of the containing Namespace
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 2.5.5, 0.0.0-20260617103935-d3c1cc64b1ae
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: partial
Summary
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.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- openbao openbao
fixed in 2.5.5
- github.com/openbao/openbaoGo
fixed in 0.0.0-20260617103935-d3c1cc64b1ae; From 0.1.0
- github.com/openbao/openbaoGo
fixed in 0.0.0-20260617103935-d3c1cc64b1ae
- github.com/openbao/openbaoGo
From 0.1.0 · through 2.5.4