| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| OpenBao is an open source identity-based secrets management system. Prior to 2.5.5, an OpenBao user with access to sys/leases/revoke/:lease_id in one namespace could revoke a lease in another namespace when the foreign lease_id was known, bypassing namespace ACL isolation. The affected lease lookup routing in vault/expiration.go allowed FetchLeaseInfo and loadEntry to resolve cached or stored lease data outside the request namespace, allowing a tenant that intentionally disclosed a lease identifier to have the lease and its underlying credential revoked by another tenant. This issue is fixed in version 2.5.5. |
| OpenBao is an open source identity-based secrets management system. Prior to 2.5.5, an authenticated OpenBao caller with write access to transit/keys/* could terminate the server process by setting derived to true while the type parameter selected rsa-, ecdsa-, or ed25519. The Transit policy creation path in builtin/logical/transit/backend.go and sdk/helper/keysutil/policy.go could reach an error path that double-unlocked a mutex while handling this invalid asymmetric derived-key combination, causing a panic, no HTTP response, process exit, and denial of service. JSON and HCL key-creation requests can express the triggering combination. This issue is fixed in version 2.5.5. |
| OpenBao is an open source identity-based secrets management system. Prior to 2.5.5, OpenBao used EscapeLDAPValue, an RFC 4514 distinguished-name escaping function, where RFC 4515 LDAP search-filter escaping was required in sdk/helper/ldaputil/client.go GetUserDN. With the LDAP authentication backend configured for an Active Directory UPNDomain path or UserDN and UserAttr binding, an attacker-controlled username containing filter metacharacters could alter the search predicate and select a different directory entry because EscapeLDAPValue does not neutralize the characters handled by ldap.EscapeFilter. A resulting token could be associated with another LDAP identity and gain access to secrets, policies, or modification capabilities assigned to that identity. This issue is fixed in version 2.5.5. |
| OpenBao is an open source identity-based secrets management system. Prior to 2.5.5, OpenBao users granted capabilities on /sys/namespaces/root within a non-root namespace could exploit special handling of the literal root path in namespace canonicalization. The /sys/namespaces/* endpoint family can resolve its containing namespace through a path prefix or X-Vault-Namespace header. ACL checks occurred before root canonicalized to an empty path, causing /sys/namespaces/root to resolve to the system backend's containing namespace and allowing permitted lookups, deletion, locking, or custom metadata changes against that direct containing namespace. The root namespace and arbitrary unrelated namespaces are not affected, and available operations depend on the capabilities granted on the path and subpaths such as /api-lock. This issue is fixed in version 2.5.5. |
| OpenBao is an open source identity-based secrets management system. Prior to version 2.5.4, OpenBao's namespaces provide multi-tenant separation. A tenant who intentionally leaks lease identifiers can have their lease and underlying credential revoked or renewed by a user in another tenant via the legacy, undocumented `sys/revoke` and `sys/renew` endpoints. This is fixed in OpenBao v2.5.4. |
| OpenBao is an open source identity-based secrets management system. Prior to version 2.5.4, in OpenBao's Kerberos auth method on the `GET` handler, or when an `Authorization: Negotiate` header is supplied, the response is includes a `logical.Auth` object in addition to an error message. This results in tokens being created with only the default policy, default TTL, and no entity information, which are hidden by the returned error message. No access to these tokens by the caller occurs and the authentication token is not ever made accessible outside of `sys/raw`. This is fixed in OpenBao v2.5.4. As a workaround, users may set a rate limit quota to limit the creation of these paths. As the path is unauthenticated, it isn't possible to deny access to it. |
| OpenBao is an open source identity-based secrets management system. Prior to version 2.5.4, OpenBao's inline auth functionality incorrectly redacted audit log entries, resulting in non-auth headers being removed and auth-related headers being retained in cleartext. This requires an attacker to compromise access to the audit device. Operators should review leaked source authentication material and rotate it as appropriate. This is fixed in OpenBao v2.5.4. |
| OpenBao is an open source identity-based secrets management system. Prior to 2.5.3, 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. This vulnerability is fixed in 2.5.3. |
| OpenBao is an open source identity-based secrets management system. Prior to version 2.5.3, `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. Version 2.5.3 contains a patch. |
| OpenBao is an open source identity-based secrets management system. OpenBao's namespaces provide multi-tenant separation. Prior to version 2.5.3, a tenant who leaks token accessors can have their token revoked or renewed by a privileged administrator in another tenant. This is addressed in v2.5.3. |
| OpenBao is an open source identity-based secrets management system. Prior to version 2.5.3, 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 original from HashiCorp Vault. The vulnerability is addressed in v2.5.3. As a workaround, 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.3, OpenBao's Certificate authentication method, when a token renewal is requested and `disable_binding=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. 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 original from HashiCorp Vault. This is addressed in v2.5.3. As a workaround, 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 does not prompt for user confirmation when logging in via JWT/OIDC and a role with `callback_mode` 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 `callback_mode=direct` or enforcing confirmation for every session on the token issuer side for the Client ID used by OpenBao. |
| 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 `callback_mode=direct` configured are vulnerable to XSS via the `error_description` 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 `error_description` parameter has been replaced with a static error message in v2.5.2. The vulnerability can be mitigated by removing any roles with `callback_mode` set to `direct`. |
| OpenBao is an open source identity-based secrets management system. Prior to version 2.4.4, 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: an operator in the root namespace has access to identity/groups endpoints and 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. This issue has been patched in version 2.4.4. |
| 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. |
| OpenBao's AWS Plugin generates AWS access credentials based on IAM policies. Prior to version 0.1.1, the AWS Plugin is vulnerable to cross-account IAM role Impersonation in the AWS auth method. 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. This vulnerability has been patched in version 0.1.1 of the auth-aws plugin. A workaround for this issue involves guaranteeing that IAM role names are unique across all AWS accounts that could potentially interact with your OpenBao environment, and to audit for any duplicate IAM roles. |
| OpenBao exists to provide a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. In versions 0.1.0 through 2.3.1, 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. To work around, ensure that all codes are first normalized before submitting to the OpenBao endpoint. TOTP code verification is a privileged action; only trusted systems should be verifying codes. |
| OpenBao exists to provide a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. In versions 0.1.0 through 2.3.1, 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. This issue was fixed in version 2.3.2. To work around this issue, 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/. |
