CVE-2026-45808: 
Wolfi vulnerability analysis and mitigation

CVE-2026-45808 is an incorrect authorization vulnerability in OpenBao that allows authenticated users in one namespace to revoke or renew leases and credentials belonging to tenants in other namespaces, breaking multi-tenant isolation. It affects all OpenBao versions up to and including 2.5.3 (Go module github.com/openbao/openbao). The vulnerability was published on May 21, 2026, and a patch was released in v2.5.4 on May 20, 2026. The GitHub Advisory Database assigns a CVSS v4 score of 7.1 (High) based on the NVD scoring, while the OpenBao security advisory itself rates it 2.0 (Low) with stricter preconditions (GitHub Advisory, OpenBao Advisory, v2.5.4 Release).

The root cause is CWE-863 (Incorrect Authorization): the legacy, largely undocumented sys/revoke, sys/renew, sys/revoke-prefix, and sys/revoke-force endpoints did not enforce namespace boundaries when processing lease operations. These endpoints accepted lease identifiers without verifying that the requesting tenant's namespace matched the namespace of the lease owner, allowing cross-namespace lease manipulation. The fix, implemented in PR #3152, removes these legacy endpoint patterns entirely (changing route patterns from (leases/)?revoke to leases/revoke only), forcing all clients to use the properly namespace-scoped sys/leases/* equivalents. Exploitation requires the attacker to be an authenticated user in one namespace and to have obtained a valid lease identifier from another tenant's namespace (GitHub Advisory, Fix Commit, PR #3152).

Successful exploitation allows an authenticated tenant in one namespace to revoke another tenant's active leases and underlying credentials (e.g., dynamic secrets such as database passwords or cloud IAM keys), causing a denial of service for that tenant by cutting off their access to managed secrets. Alternatively, an attacker could renew a lease belonging to another namespace, potentially extending the validity of credentials they should not control — for example, prolonging access to a compromised credential set. There is no confidentiality or integrity impact on the vulnerable system itself; the primary impact is availability disruption to affected tenants (GitHub Advisory, OpenBao Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Feedly). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires an authenticated user with low privileges in one namespace who has obtained a lease identifier from another namespace — a precondition that limits practical exploitability. No threat actor attribution is available. The EPSS score is not yet published for this CVE.

1. Obtain authentication: Acquire a valid OpenBao token with at least low-privilege access to any namespace on the target OpenBao instance (e.g., via a free-trial or shared-tenant account).
2. Obtain a cross-namespace lease identifier: Convince or observe a tenant in another namespace to leak their lease identifier (e.g., via logs, shared tooling, or social engineering), since lease IDs are the only prerequisite for exploitation.
3. Send a revocation request via the legacy endpoint: Issue an HTTP PUT request to the legacy sys/revoke/<lease_id> endpoint (not the namespace-scoped sys/leases/revoke/<lease_id>), supplying the cross-namespace lease ID and your own valid token:

   PUT /v1/sys/revoke/<target_lease_id>
   X-Vault-Token: <attacker_token>

4. Alternatively, renew the lease: To extend a compromised credential's validity, send a PUT to sys/renew/<lease_id> with the cross-namespace lease ID.
5. Achieve impact: The target tenant's credential is revoked (disrupting their access) or renewed (extending attacker-controlled credential validity) without any namespace authorization check (GitHub Advisory, Fix Commit).

• Network/API Logs: HTTP PUT requests to /v1/sys/revoke/<lease_id> or /v1/sys/renew/<lease_id> (legacy paths, not /v1/sys/leases/revoke/ or /v1/sys/leases/renew/) originating from a token belonging to a different namespace than the lease owner.
• Audit Logs: OpenBao audit log entries showing sys/revoke or sys/renew operations where the requesting token's namespace does not match the namespace embedded in the lease_id field.
• Operational Anomalies: Unexpected lease revocations or renewals for dynamic secrets (e.g., database credentials, cloud IAM keys) in a namespace, particularly when the affected tenant did not initiate the action — observable via OpenBao's lease lookup APIs or downstream service authentication failures.

Upgrade OpenBao to version 2.5.4 or later, which removes the legacy sys/revoke, sys/renew, sys/revoke-prefix, and sys/revoke-force endpoints entirely, enforcing use of the namespace-scoped sys/leases/* equivalents (v2.5.4 Release). As an interim workaround prior to upgrading, restrict access to the legacy endpoints via OpenBao ACL policies and treat lease identifiers as sensitive secrets — avoid logging or sharing them across tenant boundaries. Network-level controls (e.g., blocking direct API access to the legacy paths) may also reduce exposure in environments where upgrading is not immediately possible (OpenBao Advisory).

The fix was authored by Alexander Scheel (cipherboy) of the OpenBao project and merged on May 20, 2026, with the advisory published the following day. The vulnerability was reported by security researcher fg0x0. Coverage appeared in Linux distribution security update channels (e.g., Fedora package updates) and German security news outlet pro-linux.de shortly after disclosure. No significant broader media or social media discussion has been identified beyond routine package update announcements (v2.5.4 Release, PR #3152).