OpenBao vulnerabilities

OpenBao is an identity-based secrets management system. Prior to version 2.5.3, when the initial namespace deletion fails, subsequent retries do not properly remove all data before marking the namespace as deleted.

OpenBao is an open source identity-based secrets management system. Prior to 2.6.0, OpenBao's handleLogicalRecovery path in http/logical.go compared the highly privileged recovery token with ordinary string equality. A remote unauthenticated attacker able to make repeated recovery mode requests and measure response timing could infer the recovery token. The recovered token could then authorize recovery mode operations that read or modify OpenBao data. This issue is fixed in version 2.6.0.

OpenBao prior to version 2.5.2 does not prompt for user confirmation when logging in via JWT/OIDC with a role set to `callback_mode=direct`. This allows an attacker to perform remote phishing by having the victim visit a URL and automatically log into the attacker's session.

OpenBao from 2.5.0 before 2.6.2 fails to enforce the PKI role allowed_ip_sans_cidr restriction on IP SANs taken from a CSR when use_csr_sans 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 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.

An incorrect authorization vulnerability in OpenBao's ACL policy cache allows tokens to reference policies from arbitrary namespaces using specially crafted policy names. An attacker holding such tokens can gain capabilities of cached policies in other namespaces, including the root namespace, and act across namespace boundaries.

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 require_request_header 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 2.2.0 before 2.6.4 and 2.7.0 before 2.7.1 contains an information disclosure vulnerability that exposes the tls_acme_eab_mac_key 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.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.

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

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

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.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 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.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 Agent's exec rendering mode could write secrets from env_template to standard output when exec.go re-created the template runner after repeated rendering failures, primarily after num_retries was reached. A process supervisor, log collector, or local user able to read that output could obtain the rendered secret values. This issue is fixed in version 2.6.0.

OpenBao prior to 2.6.0 has a vulnerability in vault/policy/acl.go where a broader wildcard ACL grant could be evaluated before more specific trailing-wildcard ACL paths with capabilities = ["deny"] for a LIST operation. When a parent path permitted LIST and a child path was denied, the trailing-slash lookup could allow listing the denied path.

In OpenBao prior to 2.6.0, templated ACL, PKI, and SSH policies could substitute attacker-controlled identity data without rejecting syntax-significant characters. In ACL templated policies, asterisks, plus signs, and slashes could alter path matching; in PKI allowed_uri_sans_template and allowed_domains policies, an asterisk could broaden certificate issuance to unauthorized domains; in SSH allowed_users and allowed_domains policies, a comma could add unauthorized principals. Exploitation requires a deployment to use templated policy data that users can freely modify; templates based on the randomly generated identity.entity.id value are not affected.

OpenBao prior to 2.5.5 has a vulnerability where an authenticated caller with write access to transit/keys/* can terminate the server process by setting derived to true while the type parameter selected rsa-, ecdsa-, or ed25519. A mutex double-unlock error leads to a panic, no HTTP response, and denial of service.

OpenBao prior to 2.5.5 allows users granted capabilities on /sys/namespaces/root within a non-root namespace to exploit special handling of the literal root path in namespace canonicalization. ACL checks occur before root canonicalizes to an empty path, so /sys/namespaces/root resolves to the system backend's containing namespace, allowing permitted lookups, deletion, locking, or custom metadata changes against that namespace.

OpenBao prior to 2.5.5 allows a user with access to sys/leases/revoke/:lease_id in one namespace to revoke a lease in another namespace when the foreign lease_id is known. The lease lookup routing in vault/expiration.go lets FetchLeaseInfo and loadEntry resolve lease data outside the request namespace, enabling one tenant to revoke another tenant's lease and underlying credential.

OpenBao prior to 2.5.5 uses EscapeLDAPValue (an RFC 4514 DN escaping function) where RFC 4515 LDAP search-filter escaping is required in GetUserDN. With the LDAP authentication backend configured for Active Directory, an attacker-controlled username containing filter metacharacters can alter the search predicate and select a different directory entry, allowing a token to be associated with another identity and gain access to its secrets.

OpenBao before version 2.5.4 has a vulnerability in the Kerberos auth method where the response to a GET request or with an Authorization: Negotiate header includes a logical.Auth object in addition to an error message. This results in tokens being created with default policy, default TTL, and no entity information, hidden by the error message. These tokens are not accessible to the caller or outside sys/raw.

OpenBao prior to version 2.5.4 has a vulnerability in namespaces where 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.

OpenBao before version 2.5.4 has a vulnerability in the inline auth functionality that incorrectly redacts audit log entries, removing non-auth headers and retaining auth-related headers in cleartext. This requires an attacker to compromise access to the audit device.

OpenBao versions prior to 2.5.2 with OIDC/JWT authentication enabled and a role configured with `callback_mode=direct` are vulnerable to XSS via the `error_description` parameter on the failed authentication page. An attacker can steal the token used in the Web UI by a victim.

In OpenBao, a privileged operator could use the identity group subsystem to add a root policy to a group, escalating their own or another user's permissions. This affects operators in the root namespace with access to identity/groups endpoints but without policy access. The issue is patched in version 2.4.4.

OpenBao is a secrets management system. Prior to version 2.4.2, the audit log did not properly redact fields when subsystems sent []byte parameters instead of strings. This includes sys/raw with encoding=base64 and Transit signing with Ed25519 keys, causing data exposure in audit logs. The issue is fixed in 2.4.2.

In OpenBao versions 2.2.0 to 2.4.1, the audit log failed to properly redact raw HTTP bodies for some endpoints. This may leak short-lived ACME verification codes and OIDC auth and token response codes along with claims in audit logs.

OpenBao versions prior to 2.4.1 may use significantly more memory after decoding JSON than its serialized version, similar to a zip bomb, with factors reaching approximately 35. This allows bypassing the max_request_size parameter and conducting a denial of service attack through memory exhaustion by an unauthenticated attacker, as well as increased CPU consumption in the audit subsystem.