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

CVE-2026-63131: OpenBao Authentication Bypass Vulnerability

CVE-2026-63131 is an authentication bypass vulnerability in OpenBao that allows unauthorized LIST operations on denied paths through wildcard ACL evaluation flaws. This article covers technical details, affected versions, impact assessment, and mitigation strategies.

Updated:

CVE-2026-63131 Overview

CVE-2026-63131 is an authorization flaw in OpenBao, an open source identity-based secrets management system. Versions prior to 2.6.0 evaluate wildcard Access Control List (ACL) grants in the wrong order for LIST operations. When a parent path permits LIST and a child path is explicitly denied via capabilities = ["deny"], the trailing-slash lookup in vault/policy/acl.go can still authorize listing the denied path. The result is a policy bypass that exposes the names of secrets under paths administrators believed to be restricted. Only LIST operations are within the advisory's affected scope [CWE-863].

Critical Impact

Authenticated users with a broad wildcard LIST grant can enumerate secret paths that a more specific deny rule was intended to block.

Affected Products

  • OpenBao versions prior to 2.6.0
  • Deployments relying on wildcard ACL policies combined with explicit deny capabilities
  • The vault/policy/acl.go policy evaluation component

Discovery Timeline

Technical Details for CVE-2026-63131

Vulnerability Analysis

OpenBao policies support hierarchical path matching, including trailing-wildcard rules. Administrators commonly combine a permissive wildcard grant with a more specific capabilities = ["deny"] rule to carve out restricted subtrees. The ACL evaluator in vault/policy/acl.go handled LIST operations by stripping the trailing slash and consulting non-exact path rules before checking the more specific trailing-wildcard rules. This ordering allowed a broader wildcard grant to satisfy the request before the deny rule was consulted.

Because LIST returns the names of child entries, a successful bypass reveals the identifiers of secrets stored under the protected path. Other operation types such as read, write, and delete are outside the advisory's affected scope. Exploitation requires an authenticated identity that already holds a wildcard LIST grant, which limits the attack surface to insider or credential-compromise scenarios.

Root Cause

The root cause is an ordering bug in policy evaluation. The pre-patch logic performed the trailing-slash lookup before evaluating the full path against non-exact rules, inverting the documented "most specific rule wins" precedence described in the OpenBao policy syntax documentation. A shorter wildcard match therefore took priority over a longer, more specific deny match.

Attack Vector

An authenticated network-adjacent user issues a LIST request against a path that is covered by both a wildcard allow rule and a more specific deny rule. The evaluator matches the wildcard rule first and returns the child entries, disclosing secret names that policy intended to hide.

go
// Pre-patch (vulnerable) and post-patch logic in vault/policy/acl.go
// Source: https://github.com/openbao/openbao/commit/2e9625d6cebe4639d051ef53dd6ce7c49914ae6a

-	// List and Scan operations need to check without the trailing slash first,
-	// because there could be other rules with trailing wildcards that will
-	// match the path.
-	if op == logical.ListOperation && strings.HasSuffix(path, "/") {
+	permissions = a.CheckAllowedFromNonExactPaths(path, false)
+	if permissions != nil {
+		capabilities = permissions.CapabilitiesBitmap
+		goto CHECK
+	}
+
+	// List and Scan operations need to check with the trailing slash first,
+	// as they will always be the most specific rule (according to the policy
+	// syntax docs, the most specific rule wins: a match which isn't present
+	// above but is here must be one which is shorter and thus is lower
+	// priority).
+	if (op == logical.ListOperation || op == logical.ScanOperation) && strings.HasSuffix(path, "/") {
 		permissions = a.CheckAllowedFromNonExactPaths(strings.TrimSuffix(path, "/"), false)
 		if permissions != nil {
 			capabilities = permissions.CapabilitiesBitmap
 			goto CHECK
 		}
 	}

The patch reorders evaluation so the exact-path lookup runs first, ensuring more specific deny rules take precedence over broader wildcard grants.

Detection Methods for CVE-2026-63131

Indicators of Compromise

  • Successful LIST audit log entries against paths that are explicitly denied by ACL policy
  • Repeated LIST requests from a single token enumerating child paths under a wildcard-granted mount
  • Unexpected token capability lookups (sys/capabilities-self) preceding LIST operations on sensitive mounts

Detection Strategies

  • Enable OpenBao audit devices and query for LIST operations targeting paths that overlap with any capabilities = ["deny"] policy rule.
  • Correlate token identity, policy set, and requested path to identify grants that combine wildcards with sibling deny rules.
  • Run a policy linter or unit test that asserts denied paths return 403 for LIST in the current OpenBao version.

Monitoring Recommendations

  • Forward OpenBao audit logs to a centralized analytics platform and alert on LIST success where policy intent is deny.
  • Track the deployed OpenBao version across the fleet and flag any node below 2.6.0.
  • Baseline normal LIST volume per token and alert on enumeration spikes.

How to Mitigate CVE-2026-63131

Immediate Actions Required

  • Upgrade all OpenBao servers to version 2.6.0 or later as published in the OpenBao Release v2.6.0 notes.
  • Audit existing policies for combinations of wildcard grants and sibling deny rules on LIST-sensitive mounts.
  • Rotate any secret whose name may have been disclosed through an unauthorized LIST operation.

Patch Information

The issue is fixed in OpenBao 2.6.0 via OpenBao Pull Request #3389 and the backport in OpenBao Pull Request #3474. The corresponding code changes are in commits 2e9625d and f58d848. Full advisory details are in GHSA-xp3c-3jw3-4vcr.

Workarounds

  • Replace broad wildcard LIST grants with explicit path enumeration until the upgrade is complete.
  • Split sensitive child paths into a separate mount that no wildcard policy covers.
  • Restrict tokens holding wildcard LIST capabilities to short TTLs and monitored roles.
bash
# Example: verify OpenBao server version after upgrade
bao status | grep -i version

# Example: enumerate policies that mix wildcards with deny rules for review
for p in $(bao policy list); do
  echo "=== $p ==="
  bao policy read "$p" | grep -E 'path|capabilities'
done

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

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.