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