Focus on openbao vulnerabilities and metrics.
Last updated: 16 Jan 2026, 23:25 UTC
This page consolidates all known Common Vulnerabilities and Exposures (CVEs) associated with openbao. We track both calendar-based metrics (using fixed periods) and rolling metrics (using gliding windows) to give you a comprehensive view of security trends and risk evolution. Use these insights to assess risk and plan your patching strategy.
For a broader perspective on cybersecurity threats, explore the comprehensive list of CVEs by vendor and product. Stay updated on critical vulnerabilities affecting major software and hardware providers.
Total openbao CVEs: 9
Earliest CVE date: 04 Mar 2024, 20:15 UTC
Latest CVE date: 25 Nov 2025, 01:15 UTC
Latest CVE reference: CVE-2025-64761
30-day Count (Rolling): 0
365-day Count (Rolling): 5
Calendar-based Variation
Calendar-based Variation compares a fixed calendar period (e.g., this month versus the same month last year), while Rolling Growth Rate uses a continuous window (e.g., last 30 days versus the previous 30 days) to capture trends independent of calendar boundaries.
Month Variation (Calendar): -100.0%
Year Variation (Calendar): 25.0%
Month Growth Rate (30-day Rolling): -100.0%
Year Growth Rate (365-day Rolling): 25.0%
Average CVSS: 0.0
Max CVSS: 0
Critical CVEs (≥9): 0
| Range | Count |
|---|---|
| 0.0-3.9 | 9 |
| 4.0-6.9 | 0 |
| 7.0-8.9 | 0 |
| 9.0-10.0 | 0 |
These are the five CVEs with the highest CVSS scores for openbao, sorted by severity first and recency.
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.
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/.
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, 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. This is fixed in version 2.3.2. To work around this issue, existing users may apply rate-limiting quotas on the authentication endpoints:, see https://openbao.org/api-docs/system/rate-limit-quotas/.
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.
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.
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’s SSH secrets engine did not require the valid_principals list to contain a value by default. If the valid_principals and default_user 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 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.