CVE-2026-63132: OpenBao Auth Bypass Vulnerability

CVE-2026-63132 Overview

OpenBao is an open source identity-based secrets management system forked from HashiCorp Vault. CVE-2026-63132 is a timing side-channel vulnerability in the handleLogicalRecovery path in http/logical.go. Prior to version 2.6.0, OpenBao compared the highly privileged recovery token against user-supplied input using ordinary string equality. A remote unauthenticated attacker able to issue repeated recovery mode requests and measure response timing could infer the recovery token byte by byte. The recovered token authorizes recovery mode operations that read or modify OpenBao data. The issue is tracked under [CWE-208] (Observable Timing Discrepancy) and is fixed in OpenBao 2.6.0.

Critical Impact
A network-based attacker can recover the recovery token via timing analysis and gain full read/write access to secrets managed by OpenBao in recovery mode.

Affected Products

OpenBao versions prior to 2.6.0
OpenBao deployments exposing the recovery mode HTTP endpoint
Downstream distributions bundling vulnerable OpenBao releases

Discovery Timeline

2026-09-23 - CVE-2026-63132 published to the National Vulnerability Database (NVD)
2026-09-23 - Last updated in NVD database

Technical Details for CVE-2026-63132

Vulnerability Analysis

The flaw resides in OpenBao's recovery mode HTTP handler, handleLogicalRecovery, defined in http/logical.go. Recovery mode is a privileged operational state that lets operators repair a damaged OpenBao cluster, and it is gated by a single recovery token. The handler validated the presented token by using Go's native string equality operator, which short-circuits at the first differing byte. This behavior leaks information about how many leading bytes matched via response time.

An attacker who can reach the recovery HTTP endpoint can send crafted tokens and measure server response latency across many samples. By statistically averaging over network jitter, the attacker recovers each token byte incrementally. Once the full recovery token is inferred, the attacker can authenticate to recovery mode and perform arbitrary read or modify operations on OpenBao storage.

Root Cause

The root cause is the use of a non-constant-time comparison for a secret authentication value. String equality (==) in Go returns as soon as it finds a byte mismatch. When such a comparison is used against a secret, execution time correlates with the length of the matching prefix, enabling classic timing side-channel attacks classified as [CWE-208].

Attack Vector

Exploitation requires network reachability to the OpenBao recovery mode HTTP interface. No authentication or user interaction is required. The attacker submits recovery mode requests with candidate tokens and records precise response timings. Attack complexity is elevated because the attacker must overcome network noise and application jitter, but repeated sampling makes timing extraction feasible over typical operational network paths.

// Patch: http/logical.go switches to crypto/subtle for constant-time comparison
 package http
 
 import (
+	"crypto/subtle"
 	"crypto/x509"
 	"encoding/base64"
 	"encoding/json"

Source: GitHub OpenBAO Commit 0f2d90c

The fix imports crypto/subtle and uses subtle.ConstantTimeCompare for the recovery token check, eliminating the timing signal.

Detection Methods for CVE-2026-63132

Indicators of Compromise

High volumes of requests to OpenBao recovery mode HTTP endpoints from a single source or narrow IP range
Repeated authentication failures against the recovery path in http/logical.go prior to a successful recovery-mode authentication
Unexpected transitions of OpenBao nodes into recovery mode outside of scheduled maintenance windows
Recovery mode read or write operations that do not correlate with an authorized operator ticket

Detection Strategies

Alert on any inbound network traffic reaching the recovery mode endpoint from sources outside of the operations management network
Baseline normal recovery mode usage frequency and alert on statistical deviations, particularly bursts of failed attempts
Correlate OpenBao audit logs with network flow data to detect probing patterns consistent with timing-oracle extraction

Monitoring Recommendations

Enable OpenBao audit devices to capture all recovery mode request metadata and forward logs to a centralized SIEM
Monitor process and container telemetry on OpenBao hosts for unauthorized recovery mode restarts
Track outbound egress from OpenBao hosts to detect exfiltration following a successful recovery mode compromise

How to Mitigate CVE-2026-63132

Immediate Actions Required

Upgrade OpenBao to version 2.6.0 or later, which replaces the vulnerable comparison with crypto/subtle.ConstantTimeCompare
Restrict network access to the OpenBao recovery mode endpoint to trusted operator networks only via firewall or service mesh policy
Rotate any recovery tokens that may have been exposed to untrusted networks prior to patching
Review OpenBao audit logs for signs of prior recovery mode probing or unauthorized access

Patch Information

The fix ships in OpenBao Release v2.6.0. It was delivered through commits 0f2d90c and 763625a, landing through Pull Request 3388 and Pull Request 3472. The full advisory is published as GHSA-34fc-gh42-pj53.

Workarounds

Block all network access to the recovery mode HTTP listener except from a hardened bastion or management jump host
Avoid running OpenBao in recovery mode except during active maintenance, and shut down recovery mode immediately after use
Deploy a reverse proxy in front of OpenBao that enforces mutual TLS authentication on the recovery path

bash

# Example: restrict recovery mode endpoint using iptables to a management CIDR
iptables -A INPUT -p tcp --dport 8200 -s 10.10.0.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 8200 -j DROP