CVE-2026-45808: OpenBao Auth Bypass Vulnerability

CVE-2026-45808 Overview

OpenBao is an open source identity-based secrets management system that uses namespaces to provide multi-tenant separation. CVE-2026-45808 is an authorization flaw (CWE-863) affecting OpenBao versions prior to 2.5.4. The legacy, undocumented sys/revoke and sys/renew endpoints fail to enforce namespace boundaries on lease operations. A tenant who obtains or is given a lease identifier from another tenant can revoke or renew that lease and its underlying credential. The issue is tracked as GHSA-v8v8-cm84-m686 and is resolved in OpenBao v2.5.4.

Critical Impact
Authenticated tenants can revoke or renew leases and credentials belonging to other tenants, breaking the multi-tenant isolation guarantee of OpenBao namespaces.

Affected Products

OpenBao versions prior to 2.5.4
Deployments using namespaces for multi-tenant separation
Environments exposing legacy sys/revoke and sys/renew endpoints

Discovery Timeline

2026-08-07 - CVE-2026-45808 published to NVD
2026-08-13 - Last updated in NVD database

Technical Details for CVE-2026-45808

Vulnerability Analysis

OpenBao namespaces are intended to enforce strict tenant isolation. Each tenant should only operate on leases and credentials scoped to its own namespace. The legacy endpoints sys/revoke, sys/renew, sys/revoke-prefix, and sys/revoke-force did not apply namespace-aware authorization checks. An authenticated tenant in namespace A that possesses a lease identifier from namespace B can submit that identifier to the legacy endpoints and trigger revocation or renewal.

The practical outcome is that a tenant can invalidate another tenant's dynamic database credentials, cloud secrets, or PKI leases. This produces service disruption for the victim tenant and is reflected in the availability-only CVSS impact. Confidentiality and integrity of the victim's secrets are not directly compromised because the endpoints operate on lease lifecycle, not secret contents.

Root Cause

The root cause is missing namespace scope enforcement in the legacy lease management handlers. The endpoints predate namespace multi-tenancy and treated all lease identifiers as belonging to a flat global lease store. Because authorization was based only on the caller's token validity and not on the lease's owning namespace, cross-namespace operations succeeded when they should have been rejected.

Attack Vector

Exploitation requires an authenticated token in any namespace and knowledge of a target lease identifier. Lease identifiers are typically opaque and not shared, so the advisory frames the attack around a tenant who intentionally leaks their own lease ID to another tenant. Once the identifier is known, the attacker calls sys/revoke or sys/renew with the leaked ID and OpenBao performs the operation without checking namespace ownership.

 	}
 
 	// Some sudo paths have templated fields in them.
-	// (e.g. /sys/revoke-prefix/{prefix})
+	// (e.g. /sys/leases/revoke-prefix/{prefix})
 	// The values in the sudoPaths map are actually regular expressions,
 	// so we can check if our path matches against them.
 	for _, sudoPathRegexp := range sudoPaths {

Source: openbao commit c0495646. The patch removes the legacy top-level paths and routes lease operations exclusively through the namespace-aware sys/leases/* endpoints.

Detection Methods for CVE-2026-45808

Indicators of Compromise

Audit log entries showing sys/revoke or sys/renew requests targeting lease IDs that do not belong to the caller's namespace
Unexpected lease revocations reported by tenants whose credentials suddenly stop working
Requests to sys/revoke-prefix or sys/revoke-force from tokens that should not have cross-namespace scope

Detection Strategies

Parse OpenBao audit device output and correlate the request path, caller namespace, and the namespace embedded in the lease ID accession record
Alert when the caller namespace differs from the lease owner namespace for any sys/revoke* or sys/renew operation
Baseline normal use of legacy endpoints per tenant and flag deviations, since most modern clients call sys/leases/* instead

Monitoring Recommendations

Enable an OpenBao audit device on all listeners and ship logs to a centralized data platform for correlation
Track sudden spikes in lease revocation counts per namespace as a downstream signal of abuse
Monitor authentication and lease telemetry alongside application error rates to detect service disruption caused by unauthorized revocation

How to Mitigate CVE-2026-45808

Immediate Actions Required

Upgrade OpenBao to version 2.5.4 or later, which removes the vulnerable legacy endpoints
Inventory all tokens and policies that grant access to sys/revoke, sys/renew, sys/revoke-prefix, and sys/revoke-force
Review audit logs for prior cross-namespace calls to the legacy endpoints and notify affected tenants

Patch Information

The fix is included in OpenBao v2.5.4 and delivered via pull request #3152. The changelog entry states: core: Remove legacy lease endpoints (sys/revoke, sys/renew, sys/revoke-prefix, and sys/revoke-force) due to cross-namespace lease modification. Callers must migrate to the namespace-aware sys/leases/revoke and sys/leases/renew endpoints.

Workarounds

Restrict policies so that no token can call the legacy sys/revoke, sys/renew, sys/revoke-prefix, or sys/revoke-force paths
Front OpenBao with a proxy or WAF rule that rejects requests to the legacy top-level lease endpoints while migration to v2.5.4 is in progress
Rotate any lease identifiers that were shared across tenant boundaries and treat leaked IDs as compromised

bash

# Deny legacy lease endpoints in an OpenBao policy until upgrade completes
path "sys/revoke"          { capabilities = ["deny"] }
path "sys/renew"           { capabilities = ["deny"] }
path "sys/revoke-prefix/*" { capabilities = ["deny"] }
path "sys/revoke-force/*"  { capabilities = ["deny"] }