Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-55774

CVE-2026-55774: OpenBao Auth Bypass Vulnerability

CVE-2026-55774 is an authentication bypass flaw in OpenBao allowing users to revoke leases across namespaces, breaking ACL isolation. This post explains its impact, affected versions, and mitigation steps.

Published:

CVE-2026-55774 Overview

CVE-2026-55774 is a broken authorization vulnerability [CWE-863] in OpenBao, an open source identity-based secrets management system. Versions prior to 2.5.5 allow a tenant with access to sys/leases/revoke/:lease_id in one namespace to revoke leases in a different namespace. The flaw stems from lease lookup routing in vault/expiration.go, where FetchLeaseInfo and loadEntry resolve cached or stored lease data outside the request namespace. When a foreign lease_id is disclosed, another tenant can revoke the lease and invalidate the underlying credential, bypassing namespace ACL isolation.

Critical Impact

An authenticated tenant in one namespace can revoke leases and their underlying credentials in another namespace when they learn the target lease identifier, breaking multi-tenant isolation guarantees.

Affected Products

  • OpenBao versions prior to 2.5.5
  • OpenBao multi-namespace deployments serving multiple tenants
  • OpenBao secrets engines that issue dynamic credentials via leases

Discovery Timeline

  • 2026-09-15 - CVE CVE-2026-55774 published to NVD
  • 2026-09-15 - Last updated in NVD database

Technical Details for CVE-2026-55774

Vulnerability Analysis

OpenBao uses namespaces to isolate tenants, and access control lists (ACLs) restrict which lease identifiers a caller may act on within their own namespace. The lease revocation path in vault/expiration.go accepts a lease_id from the request and resolves it against cached or stored lease entries. Prior to 2.5.5, that resolution did not enforce that the resolved lease belonged to the caller's namespace. A caller with the sys/leases/revoke/:lease_id capability in namespace A could pass a lease_id belonging to namespace B and cause revocation. The revocation then invalidates the underlying secret backend credential, producing a cross-tenant denial of the issued secret.

Root Cause

The root cause is missing authorization enforcement between the request namespace context and the resolved lease entry's namespace. FetchLeaseInfo and loadEntry fetched lease data by identifier without validating that ns.ID == le.namespace.ID before executing the revoke operation. Exploitation requires knowledge of a foreign lease identifier, which is normally opaque but may be leaked through logs, audit devices, application errors, or intentional disclosure by a cooperating tenant.

Attack Vector

The attack is network-based and requires an authenticated OpenBao token with revoke privileges in any namespace. The attacker submits a revoke request against sys/leases/revoke/:lease_id, supplying a lease identifier that belongs to a different namespace. The server processes the revoke without a cross-namespace check and invalidates the target lease.

go
// Patch excerpt from vault/expiration.go (context: renew/revoke path)
// The removed block previously enforced namespace equality; the fix moves
// enforcement into the lease lookup routing itself.

		return logical.ErrorResponse("lease does not correspond to a secret"), nil
	}

-	ns, err := namespace.FromContext(ctx)
-	if err != nil {
-		return nil, err
-	}
-	if ns.ID != le.namespace.ID {
-		return nil, errors.New("cannot renew a lease across namespaces")
-	}
-
	sysViewCtx := namespace.ContextWithNamespace(ctx, le.namespace)
	sysView := m.router.MatchingSystemView(sysViewCtx, le.Path)
	if sysView == nil {

Source: GitHub Commit 9ba1413

Detection Methods for CVE-2026-55774

Indicators of Compromise

  • Audit log entries showing sys/leases/revoke/* requests where the request namespace differs from the namespace embedded in the revoked lease_id.
  • Unexpected revocation events for dynamic credentials, followed by application authentication failures against downstream systems such as databases or cloud IAM.
  • Repeated revoke calls from a single token against lease identifiers that were never issued to that token's namespace.

Detection Strategies

  • Enable and forward OpenBao audit device logs, then correlate the caller namespace, token accessor, and lease_id prefix on every revoke operation.
  • Alert when the namespace segment encoded in a lease_id does not match the namespace field of the requesting token.
  • Baseline normal revoke volume per tenant and flag deviations, especially bursts of revokes against foreign lease identifiers.

Monitoring Recommendations

  • Ship OpenBao audit logs to a centralized analytics platform and retain them long enough to reconstruct cross-namespace activity.
  • Monitor secrets engines for spikes in credential re-issuance immediately following revoke events, which can indicate exploitation impact.
  • Review any process, script, or log sink that handles lease_id values and confirm those identifiers are not exposed to other tenants.

How to Mitigate CVE-2026-55774

Immediate Actions Required

  • Upgrade OpenBao to version 2.5.5 or later, or to 2.6.0, which contain the fix for the cross-namespace lease routing flaw.
  • Rotate credentials issued by dynamic secrets engines if audit logs show revoke activity that cannot be attributed to the owning namespace.
  • Review and tighten ACL policies granting sys/leases/revoke/* capability so it is limited to operators that require it.

Patch Information

The fix is delivered in OpenBao 2.5.5 and included in 2.6.0. See the GitHub Security Advisory GHSA-c36x-h252-g9x2, GitHub Pull Request #3307, GitHub Pull Request #3310, and the GitHub Release v2.5.5 notes. The patch removes the fragile equality check in the renew/revoke path and enforces namespace isolation at the lease lookup routing layer in vault/expiration.go.

Workarounds

  • Restrict the sys/leases/revoke/* capability in ACL policies so only trusted operators can invoke lease revocation.
  • Treat lease_id values as sensitive and prevent them from appearing in shared logs, error messages, or cross-tenant channels.
  • Where feasible, isolate high-value tenants into separate OpenBao clusters until the upgrade to 2.5.5 is complete.
bash
# Verify the running OpenBao version and confirm the fix is applied
bao status | grep -i version
bao version

# Example: list policies that grant lease revocation capability
bao policy list | while read p; do
  bao policy read "$p" | grep -E 'sys/leases/revoke' && echo "  ^ in policy: $p"
done

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.