Timing flaw in openbao OpenBao can expose privileged recovery tokens

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 OpenBao: versions < 2.6.0 are identified as affected.
• OpenBao 2.6.0 is identified as patched, with the vendor change using constant-time token comparison in recovery mode.
• The available evidence does not provide a separate status for other product lines or downstream builds outside the boundary above.

The vulnerable component is handleLogicalRecovery in http/logical.go. OpenBao compared the highly privileged recovery token with ordinary string equality rather than a comparison whose execution time is independent of the matching prefix. The attacker controls repeated recovery mode requests and can measure response timing differences. Those timing observations can allow the attacker to infer the single recovery token that protects recovery mode API operations. The attack is network-reachable and does not require prior authentication, but it depends on repeated measurements and on recovery mode being reachable under the deployment conditions. The available evidence does not establish the number of requests required, the amount of network noise tolerated, or whether every deployment exposes recovery mode to an untrusted network.

The flaw is reachable over the network and does not require prior privileges or user interaction. An attacker must still send repeated recovery mode requests and measure response timing, so this is not a simple one-shot attack. The supplied record marks public exploit as false and does not provide a known-exploited status; that does not prove the issue has never been exploited. The available evidence identifies no exploit code, campaign, victim, or specific IOC.

An attacker who recovers the token can perform the recovery mode operations protected by that token, including reading or modifying OpenBao data. Because recovery mode is highly privileged, token compromise could bypass ordinary access controls for operations exposed through that mode. The directly supported technical impact is loss of confidentiality and integrity for data managed by OpenBao. The evidence does not confirm compromise of downstream systems, operating-system access, or a specific availability action.

Recovering the token can enable unauthorized access to highly privileged recovery mode operations. The confirmed consequences include reading OpenBao data, which may expose secrets or operational data managed by OpenBao. The attacker may also modify data through recovery mode operations authorized by the token, affecting the integrity of stored configuration or data. The evidence does not identify a specific victim, breach, dependent service outage, or concrete service-disruption scenario.

1. Upgrade OpenBao to exactly 2.6.0, which the vendor advisory and release identify as containing the fix.
2. If an immediate upgrade is not possible, reduce exposure of recovery-mode request handling to untrusted networks and restrict it to trusted administrative networks where the deployment architecture permits. This is a compensating measure derived from the network precondition, not a vendor-confirmed workaround.
3. Determine whether recovery mode on affected instances was reachable from untrusted sources. If timing probing or possible token exposure is identified, handle the recovery token and related data under the organization's incident-response process.
4. Do not treat the absence of logs or known IOCs as proof that exposure did not occur, because the public evidence does not provide a complete indicator set.

1. Inventory all servers and images running OpenBao, then compare their versions with the affected boundary in affected_summary.
2. Identify deployments that run or permit recovery mode, and determine whether recovery-mode request handling is reachable from untrusted networks.
3. Review existing network and request telemetry for repeated recovery mode requests from unauthenticated sources, especially patterns consistent with response-time measurement. This is precautionary monitoring, not a vendor-confirmed IOC.
4. If suspicious activity is found, investigate recovery mode operations and subsequent reads or modifications of OpenBao data. No specific log event has been published, and the absence of matching telemetry does not prove that a deployment is safe.