Summary
OpenBao's Recovery Mode Vulnerable To Token Leakage via Timing Attack
Advisory details
Impact
When running in the highly privileged recovery mode, OpenBao was vulnerable to a timing attack against the single recovery token. This allowed an attacker to extract the recovery token and use it to perform operations against the OpenBao instance, including reading or modification of data.
Patches
This has been patched in OpenBao v2.6.0.
References
- https://github.com/advisories/GHSA-34fc-gh42-pj53
- https://github.com/openbao/openbao/security/advisories/GHSA-34fc-gh42-pj53
- https://github.com/openbao/openbao/pull/3388
- https://github.com/openbao/openbao/pull/3472
- https://github.com/openbao/openbao/commit/0f2d90c331f25d1c6cd108638da03f4c7bd949a8
- https://github.com/hashicorp/vault/blob/main/CHANGELOG.md#203
- https://github.com/openbao/openbao/releases/tag/v2.6.0
Related vulnerabilities
All Supply chain →- MEDIUMCVE-2026-49265
Oauthlib: Timing Attack Vulnerability in PKCE code_verifier Comparison (CWE-208)
- MEDIUMCVE-2026-88010
Traefik: BasicAuth singleflight coalescing reintroduces an unauthenticated username-enumeration timing oracle
- MEDIUMCVE-2026-85725
lightrag-hku: Plaintext Passwords Compared Without Constant-Time Function
- MEDIUMCVE-2026-77582
Tinyauth: User enumeration attack by timing oracle
- MEDIUMCVE-2026-58272
Sync-in Server has Username/Login Enumeration via Timing Side-Channel on POST /api/auth/login (incomplete fix of the prior timing-attack advisory)
- MEDIUMCVE-2026-84308
phpseclib — non-constant-time X25519 scalar multiplication permits full private-key recovery