OpenBao Root Namespace Operator May Elevate Token Privileges
### Impact Accounts with access to the highly-privileged identity entity system in the root namespace may increase their scope directly to the `root` policy. While the identity system always allowed adding arbitrary policies, which in turn could contain capability grants on arbitrary paths, the `root` policy is restricted to manual generation using unseal or recovery key shares. The global `root` policy is not accessible from child namespaces. ### Patches OpenBao v2.3.2 will patch this issue. ### Workarounds Use of `denied_parameters` in any policy which has access to the affected identity endpoints (on [identity entities](https://openbao.org/api-docs/secret/identity/entity/)) may be sufficient to prohibit this type of attack. ### References This issue was disclosed to HashiCorp and is the OpenBao equivalent of the following tickets: - https://discuss.hashicorp.com/t/hcsec-2025-13-vault-root-namespace-operator-may-elevate-token-privileges/76032 - https://nvd.nist.gov/vuln/detail/cve-2025-5999
02 / AFFECTED SOFTWARE
Affected packages
114 explicit affected versions
03 / CONNECTIONS
Connected vulnerabilities
04 / EVIDENCE
Source records
OpenBao Root Namespace Operator May Elevate Token Privileges in github.com/openbao/openbao. NOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions. (If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.) The additional affected modules and versions are: github.com/openbao/openbao before v2.3.2.
### Impact Accounts with access to the highly-privileged identity entity system in the root namespace may increase their scope directly to the `root` policy. While the identity system always allowed adding arbitrary policies, which in turn could contain capability grants on arbitrary paths, the `root` policy is restricted to manual generation using unseal or recovery key shares. The global `root` policy is not accessible from child namespaces. ### Patches OpenBao v2.3.2 will patch this issue. ### Workarounds Use of `denied_parameters` in any policy which has access to the affected identity endpoints (on [identity entities](https://openbao.org/api-docs/secret/identity/entity/)) may be sufficient to prohibit this type of attack. ### References This issue was disclosed to HashiCorp and is the OpenBao equivalent of the following tickets: - https://discuss.hashicorp.com/t/hcsec-2025-13-vault-root-namespace-operator-may-elevate-token-privileges/76032 - https://nvd.nist.gov/vuln/detail/cve-2025-5999
OpenBao exists to provide a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. In versions 2.3.1 and below, accounts with access to highly-privileged identity entity systems in root namespaces were able to increase their scope directly to the root policy. While the identity system allowed adding arbitrary policies, which in turn could contain capability grants on arbitrary paths, the root policy was restricted to manual generation using unseal or recovery key shares. The global root policy was not accessible from child namespaces. This issue is fixed in version 2.3.2. To workaround this vulnerability, use of denied_parameters in any policy which has access to the affected identity endpoints (on identity entities) may be sufficient to prohibit this type of attack.
OpenBao exists to provide a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. In versions 2.3.1 and below, accounts with access to highly-privileged identity entity systems in root namespaces were able to increase their scope directly to the root policy. While the identity system allowed adding arbitrary policies, which in turn could contain capability grants on arbitrary paths, the root policy was restricted to manual generation using unseal or recovery key shares. The global root policy was not accessible from child namespaces. This issue is fixed in version 2.3.2. To workaround this vulnerability, use of denied_parameters in any policy which has access to the affected identity endpoints (on identity entities) may be sufficient to prohibit this type of attack.
05 / REFERENCES
Further evidence
- https://discuss.hashicorp.com/t/hcsec-2025-13-vault-root-namespace-operator-may-elevate-token-privileges/76032
- https://github.com/openbao/openbao/commit/9b0b5d4f345fdfb1065956f042b12cbd86cd6e0f
- https://github.com/openbao/openbao/pull/1627
- https://github.com/openbao/openbao/releases/tag/v2.3.2
- https://github.com/openbao/openbao/security/advisories/GHSA-vf84-mxrq-crqc
- https://nvd.nist.gov/vuln/detail/CVE-2025-54996
- https://nvd.nist.gov/vuln/detail/cve-2025-5999
- https://github.com/openbao/openbao
- https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/54xxx/CVE-2025-54996.json