FlawAtlas
Search the atlas
CVE-2025-54996 High

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

Exploit probability 0.3%
Published August 8, 2025
Required by Not available
Last source change July 27, 2026

02 / AFFECTED SOFTWARE

Affected packages

Unknown Unknown

114 explicit affected versions

Go github.com/openbao/openbao
Go github.com/openbao/openbao
Bitnami openbao

03 / CONNECTIONS

Connected vulnerabilities

04 / EVIDENCE

Source records

Open Source Vulnerabilities GO-2025-3857

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.

View original source
Open Source Vulnerabilities GHSA-vf84-mxrq-crqc

### 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

View original source
Open Source Vulnerabilities CVE-2025-54996

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.

View original source
Open Source Vulnerabilities BIT-openbao-2025-54996

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.

View original source

05 / REFERENCES

Further evidence