OpenBao from 2.3.0 before 2.6.3 contains an incorrect authorization vulnerability in its ACL policy cache that allows tokens to reference policies from arbitrary namespaces using specially crafted policy names. Attackers holding such tokens can gain capabilities of cached policies in other namespaces, including the root namespace, to act across namespace boundaries.

OpenBao before 2.6.4 and 2.7.x before 2.7.1 fails to write response audit entries for the unauthenticated sys/generate-root, sys/rekey, and sys/rekey-recovery-key endpoints when request audit logging succeeds but response audit logging fails. An attacker using these endpoints can complete root token generation or rekey operations without a corresponding response audit record, hindering forensic detection.

OpenBao before 2.6.3 contains an ACL bypass vulnerability that silently drops explicit deny rules based on forbidden identity metadata templates within wildcard grants. Attackers whose identity metadata contains wildcard or path segments can access paths that should be denied within the broader wildcard-granted scope.

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

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.

Impact

OpenBao's audit log experienced a regression wherein raw HTTP bodies used by few endpoints were not correctly redacted (HMAC'd). This impacted the following subsystems:

- When using the ACME functionality of PKI, this would result in short-lived ACME verification challenge codes being leaked in the audit logs. - When using the OIDC issuer functionality of the identity subsystem, auth and token response codes along with claims could be leaked in the audit logs.

Third-party plugins may be affected.

Patches

OpenBao v2.4.2 will patch this issue.

Workarounds

If users do not use the above functionality, they are not impacted. ACME verification codes are not usable after verification or challenge expiry so are of limited long-term use.

Impact

OpenBao and HashiCorp Vault allowed an attacker to perform unauthenticated, unaudited cancellation of root rekey and recovery rekey operations, effecting a denial of service.

Patches

In OpenBao v2.2.2 and later, manually setting the configuration option disableunauthedrekeyendpoints=true allows an operator to deny these rarely-used endpoints on global listeners.

In a future OpenBao release communicated on our website, we will set this to true for all users and provide an authenticated alternative.

This vulnerability has been disclosed to HashiCorp; see their website for more information.

Workarounds

If an active proxy or load balancer sits in front of OpenBao, an operator can deny requests to these endpoints from unauthorized IP ranges.

References

See the deprecation notice.

Impact

OpenBao before v2.3.0 and HashiCorp Vault as of the current v1.19.5 may leak sensitive information in logs when processing malformed data. This is separate from the earlier HCSEC-2025-09 / CVE-2025-4166.

Patches

This issue has been fixed in OpenBao v2.3.0 and later.

Workarounds

Like with HCSEC-2025-09, there is no known workaround except to ensure properly formatted requests from all clients.

Remediation

Users with the capability to search through server and audit logs for any possible exposed secrets can refer to the following snippets to aid in searching:

Audit Log

... "error":"error converting input for field \"password\": expected type 'string', got unconvertible type 'map[string]interface {}', value: '<sensitive data>'" ...

Server Log

error converting input for field "password": expected type 'string', got unconvertible type 'map[string]interface {}', value: '<sensitive data>'

If any matches are found, rotating the affected secret is advised.

References

See also: https://discuss.hashicorp.com/t/hcsec-2025-09-vault-may-expose-sensitive-information-in-error-logs-when-processing-malformed-data-with-the-kv-v2-plugin/74717

See also: https://github.com/go-viper/mapstructure/releases/tag/v2.3.0

See also: https://github.com/go-viper/mapstructure/pull/105 -> https://github.com/go-viper/mapstructure/commit/ed3f92181528ff776a0324107b8b55026e93766a

Impact

Attackers could bypass the automatic user lockout mechanisms in the OpenBao Userpass or LDAP auth systems. This was caused by different aliasing between pre-flight and full login request user entity alias attributions.

Patches

OpenBao v2.3.2 will patch this issue.

Workarounds

Existing users may apply rate-limiting quotas on the authentication endpoints: https://openbao.org/api-docs/system/rate-limit-quotas/

References

This issue was disclosed to HashiCorp and is the OpenBao equivalent of the following tickets:

- https://discuss.hashicorp.com/t/hcsec-2025-16-vault-userpass-and-ldap-user-lockout-bypass/76035 - https://nvd.nist.gov/vuln/detail/CVE-2025-6004

Impact

When using OpenBao's userpass auth method, user enumeration was possible due to timing difference between non-existent users and users with stored credentials. This is independent of whether the supplied credentials were valid for the given user.

Patches

OpenBao v2.3.2 will patch this issue.

Workarounds

Users may use another auth method or apply rate limiting quotas to limit the number of requests in a period of time: https://openbao.org/api-docs/system/rate-limit-quotas/

References

This issue was disclosed to HashiCorp and is the OpenBao equivalent of the following tickets:

- https://discuss.hashicorp.com/t/hcsec-2025-15-timing-side-channel-in-vault-s-userpass-auth-method/76034 - https://nvd.nist.gov/vuln/detail/CVE-2025-6011

Barring further information, this is also assumed to cover and remediate the following additional vulnerability:

- https://discuss.hashicorp.com/t/hcsec-2025-21-vault-user-enumeration-in-userpass-auth-method/76095 - https://nvd.nist.gov/vuln/detail/CVE-2025-6010

If this is not the case as further details emerge, a new CVE will be assigned for remediating that. Otherwise, no further CVE will be sought.

Impact

OpenBao's TOTP secrets engine could accept valid codes multiple times rather than strictly-once. This was caused by unexpected normalization in the underlying TOTP library.

Patches

OpenBao v2.3.2 will patch this issue.

In patching, codes which were not normalized (strictly N numeric digits) will now be rejected. This is a potentially breaking change.

Workarounds

TOTP code verification is a privileged action; only trusted systems should be verifying codes. Ensure that all codes are first normalized before submitting to the OpenBao endpoint.

References

This issue was disclosed to HashiCorp and is the OpenBao equivalent of the following tickets:

- https://discuss.hashicorp.com/t/hcsec-2025-17-vault-totp-secrets-engine-code-reuse/76036 - https://nvd.nist.gov/vuln/detail/CVE-2025-6014

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 deniedparameters in any policy which has access to the affected identity endpoints (on identity entities) 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

Impact

OpenBao's Login Multi-Factor Authentication (MFA) system allows enforcing MFA using Time-based One Time Password (TOTP). Due to normalization applied by the underlying TOTP library, codes were accepted which could contain whitespace; this whitespace could bypass internal rate limiting of the MFA method and allow reuse of existing MFA codes.

Patches

OpenBao v2.3.2 will patch this issue.

Workarounds

Use of rate-limiting quotas can limit an attacker's ability to exploit this: https://openbao.org/api-docs/system/rate-limit-quotas/

References

This issue was disclosed to HashiCorp and is the OpenBao equivalent of the following tickets:

- https://discuss.hashicorp.com/t/hcsec-2025-19-vault-login-mfa-bypass-of-rate-limiting-and-totp-token-reuse/76038 - https://nvd.nist.gov/vuln/detail/CVE-2025-6015

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

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

OpenBao's audit log did not appropriately redact fields when relevant subsystems sent []byte response parameters rather than strings. This includes, but is not limited to:

- sys/raw with use of encoding=base64, all data would be emitted unredacted to the audit log. - Transit, when performing a signing operation with a derived Ed25519 key, would emit public keys to the audit log.

Third-party plugins may be affected.

This issue has been present since HashiCorp Vault and continues to impact Vault as of v1.20.4.

Patches

OpenBao v2.4.2 will patch this issue.

Workarounds

If users do not use the above functionality, they are not impacted. To prohibit the use of sys/raw globally, ensure rawstorageendpoint=false is set or missing from the server configuration.

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.

Impact

Under certain threat models, OpenBao operators with privileged API access may not be system administrators and thus normally lack the ability to update binaries or execute code on the system. Additionally, privileged API operators should be unable to perform TCP connections to arbitrary hosts in the environment OpenBao is executing within. The API-driven audit subsystem granted privileged API operators the ability to do both with an attacker-controlled log prefix. Access to these endpoints should be restricted.

Patches

OpenBao v2.3.2 will patch this issue.

Workarounds

Users may deny all access to the sys/audit/ interface (with create and update) permission via policies with explicit deny grants. This would not restrict root level operators, however, for whom there are no workarounds.

This interface allowed arbitrary filesystem and network (write) access as the user the OpenBao server was running as; in conjunction with allowing custom plugins or other system processes this may enable code execution.

References

This issue was disclosed to HashiCorp and is the OpenBao equivalent of the following tickets:

- https://discuss.hashicorp.com/t/hcsec-2025-14-privileged-vault-operator-may-execute-code-on-the-underlying-host/76033 - https://nvd.nist.gov/vuln/detail/CVE-2025-6000

Summary

JSON objects after decoding might use more memory than their serialized version. It is possible to tune a JSON to maximize the factor between serialized memory usage and deserialized memory usage (similar to a zip bomb). While reproducing the issue, we could reach a factor of about 35. This can be used to circumvent the [maxrequestsize (https://openbao.org/docs/configuration/listener/tcp/) configuration parameter, which is meant to protect against Denial of Service attacks, and also makes Denial of Service attacks easier in general, as the attacker needs much less resources.

Details

The request body is parsed into a map[string]interface{} https://github.com/openbao/openbao/blob/788536bd3e10818a7b4fb00aac6affc23388e5a9/http/logical.go#L50 very early in the request handling chain (before authentication), which means an attacker can send a specifically crafted JSON object and cause an OOM crash. Additionally, for simpler requests with large numbers of strings, the audit subsystem can consume large quantities of CPU.

To remediate, set maxrequestjsonmemory and maxrequestjsonstrings.

Impact

- Unauthenticated Denial of Service

Resources

This issue was disclosed directly to HashiCorp and is the OpenBao equivalent of the following tickets:

- https://discuss.hashicorp.com/t/hcsec-2025-24-vault-denial-of-service-though-complex-json-payloads/76393 - https://nvd.nist.gov/vuln/detail/CVE-2025-6203

HashiCorp attributes the problem to the audit subsystem. For OpenBao, it was noted the problem was additionally in the requests handling logic.

OpenBao from 2.5.0 before 2.6.2 fails to enforce the PKI role allowedipsanscidr restriction on IP SANs taken from a CSR when usecsrsans is enabled. Authenticated callers with sign permission can submit a CSR with an out-of-range IP SAN to pki/sign/<role> and obtain CA-signed certificates for unauthorized IPs.

OpenBao 2.2.0 before 2.6.4 and 2.7.0 before 2.7.1 contains an information disclosure vulnerability that exposes the tlsacmeeabmackey value through the sys/config/state/sanitized endpoint. Callers of the sanitized configuration endpoint can retrieve the ACME External Account Binding MAC key used for TLS listener certificates, letting them bind to the operator's ACME account.

OpenBao before 2.6.3 contains an information disclosure vulnerability that allows attackers to leak sensitive data into audit logs by sending malformed plugin parameters. Attackers can submit requests with malformed TypeKVPair or TypeHeader field values, causing error messages containing sensitive input to be recorded in audit logs.

OpenBao before 2.6.4 and 2.7.x before 2.7.1 contains a flaw in its rate limit quota subsystem where role resolution fails for requests with form-encoded bodies or forwarded certificates, so quota rules scoped to backend-specific roles are not enforced. Valid callers can repeatedly issue tokens without consuming the configured role-based rate limit budget.

OpenBao before 2.6.4 and 2.7.x before 2.7.1 does not check Secret ID expiration at use in the AppRole auth method, leaving expired Secret IDs valid until the periodic tidy removes them. An attacker holding an expired, untidied Secret ID can log in and gain access beyond its TTL.

OpenBao before 2.6.3 contains an open redirect vulnerability in the UI's OIDC identity provider that affects users not authenticated to OpenBao. Attackers can craft OIDC links that redirect unauthenticated users to attacker-controlled destinations, enabling phishing or credential theft.

OpenBao before 2.6.3 contains a missing authorization check that allows attackers to stop Agent and Proxy services by omitting the X-Vault-Header. When requirerequestheader is enabled, attackers can send requests via server-side request forgery to /agent/v1/quit or /proxy/v1/quit to shut down these services.

OpenBao before 2.6.4 and 2.7.x before 2.7.1 does not verify, when renewing a token issued by the Kubernetes Auth method, that the service account token originally used to authenticate is still valid. An authenticated attacker can keep renewing such tokens to persist access after the Kubernetes service account has been deleted.

OpenBao from 2.3.0 before 2.6.3 contains an improper authorization vulnerability that allows privileged child-namespace tokens to modify plugin registrations because /v1/sys/plugins/catalog/ is not restricted to the root namespace. Attackers can remove existing registrations, create invalid ones, or register installed plugins through a child namespace's sys/ mount, causing denial of service.