Filtered by vendor Openbao Project
Subscriptions
Total
7 CVE
| CVE | Vendors | Products | Updated | CVSS v3.1 |
|---|---|---|---|---|
| CVE-2025-55003 | 1 Openbao Project | 1 Openbao | 2025-08-12 | 5.7 Medium |
| OpenBao exists to provide a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. In versions 2.3.1 and below, 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. This issue was fixed in version 2.3.2. To work around this, use of rate-limiting quotas can limit an attacker's ability to exploit this: https://openbao.org/api-docs/system/rate-limit-quotas/. | ||||
| CVE-2025-54997 | 1 Openbao Project | 1 Openbao | 2025-08-12 | 9.1 Critical |
| OpenBao exists to provide a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. In versions 2.3.1 and below, some OpenBao deployments intentionally limit privileged API operators from executing system code or making network connections. However, these operators can bypass both restrictions through the audit subsystem by manipulating log prefixes. This allows unauthorized code execution and network access that violates the intended security model. This issue is fixed in version 2.3.2. To workaround, users can block access to sys/audit/* endpoints using explicit deny policies, but root operators cannot be restricted this way. | ||||
| CVE-2025-55001 | 1 Openbao Project | 1 Openbao | 2025-08-12 | 6.5 Medium |
| OpenBao exists to provide a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. In versions 2.3.1 and below, OpenBao allowed the assignment of policies and MFA attribution based upon entity aliases, chosen by the underlying auth method. When the username_as_alias=true parameter in the LDAP auth method was in use, the caller-supplied username was used verbatim without normalization, allowing an attacker to bypass alias-specific MFA requirements. This issue was fixed in version 2.3.2. To work around this, remove all usage of the username_as_alias=true parameter and update any entity aliases accordingly. | ||||
| CVE-2025-54999 | 1 Openbao Project | 1 Openbao | 2025-08-12 | 3.7 Low |
| 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/. | ||||
| CVE-2025-54996 | 1 Openbao Project | 1 Openbao | 2025-08-12 | 7.2 High |
| OpenBao exists to provide a software solution to manage, store, and distribute sensitive data including secrets, certificates, and keys. In versions 2.3.1 and below, accounts with access to highly-privileged identity entity systems in root namespaces were able to increase their scope directly to the root policy. While the identity system allowed adding arbitrary policies, which in turn could contain capability grants on arbitrary paths, the root policy was restricted to manual generation using unseal or recovery key shares. The global root policy was not accessible from child namespaces. This issue is fixed in version 2.3.2. To workaround this vulnerability, use of denied_parameters in any policy which has access to the affected identity endpoints (on identity entities) may be sufficient to prohibit this type of attack. | ||||
| CVE-2025-54998 | 1 Openbao Project | 1 Openbao | 2025-08-12 | 5.3 Medium |
| 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/. | ||||
| CVE-2025-55000 | 1 Openbao Project | 1 Openbao | 2025-08-12 | 6.5 Medium |
| 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. | ||||
Page 1 of 1.