CVE-2026-55774: 
Wolfi vulnerability analysis and mitigation

CVE-2026-55774 is a cross-namespace lease revocation authorization bypass vulnerability in OpenBao, an open-source secrets management platform. Authenticated users with access to the sys/leases/revoke/:lease_id endpoint in any namespace can revoke leases — and their underlying credentials — in any other namespace, as long as the lease identifier is known, bypassing the ACLs that should enforce cross-namespace isolation. The vulnerability affects all OpenBao versions from 0.1.0 through 2.5.4 (Go module github.com/openbao/openbao). It was published on June 19, 2026, and carries a CVSS v4.0 base score of 2.1 (Low) (GitHub Advisory, OpenBao Advisory).

The root cause is Incorrect Authorization (CWE-863): the sys/leases/revoke/:lease_id path-based endpoint did not properly enforce namespace context when routing lease revocation requests. Specifically, the request handling logic in vault/request_handling.go failed to extract and validate the namespace embedded in the lease ID when the lease ID was supplied as a URL path segment (e.g., sys/leases/revoke/<lease_id>), as opposed to being supplied in the request body. This meant the namespace context was not correctly set before ACL checks, allowing a tenant in one namespace to revoke leases belonging to another namespace if they possessed the target lease identifier. The fix (commit b20b999) extended the routing logic to handle both path-segment and request-body lease ID forms, and corrected namespace context propagation in vault/expiration.go (GitHub Advisory, Fix Commit). This vulnerability is related to but distinct from CVE-2026-45808 (GHSA-v8v8-cm84-m686) and CVE-2026-40264 (GHSA-p49j-v9wc-wg57), representing an incomplete fix of the former (OpenBao Advisory).

The primary impact is an availability and integrity concern within OpenBao's multi-tenant namespace model: a malicious or compromised tenant can revoke leases and invalidate the underlying dynamic credentials (e.g., database passwords, cloud IAM tokens) belonging to another tenant's namespace, causing service disruption for that tenant. There is no confidentiality impact — the attacker cannot read secrets from other namespaces — and no subsequent system impact is expected beyond the revoked credentials. The attack requires the attacker to already hold high privileges within their own namespace and to have obtained a valid lease identifier from the target namespace, limiting the practical blast radius (GitHub Advisory, OpenBao Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). Exploitation requires an authenticated user with high privileges in at least one namespace and knowledge of a lease identifier from a target namespace — a precondition that significantly limits opportunistic exploitation. No threat actor attribution has been reported, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Nessus detection plugins (IDs 323130 and 323124) are available for identifying vulnerable instances.

1. Obtain access: Authenticate to an OpenBao instance as a user with high privileges in any namespace, ensuring access to the sys/leases/revoke/:lease_id endpoint within that namespace.
2. Obtain a target lease identifier: Acquire a lease ID from a different namespace — for example, through a tenant who intentionally or inadvertently leaks their lease identifier (e.g., via logs, API responses, or inter-tenant communication).
3. Craft the revocation request: Issue an HTTP PUT or POST request to the vulnerable path-based endpoint, embedding the cross-namespace lease ID directly in the URL path: PUT /v1/sys/leases/revoke/<target_namespace_lease_id>.
4. Bypass ACL enforcement: Because the namespace context is not correctly derived from the path-segment lease ID in vulnerable versions, the ACL check does not enforce cross-namespace restrictions, and the revocation proceeds.
5. Achieve impact: The target lease and its underlying dynamic credential (e.g., a database password or cloud token) are revoked in the other namespace, causing service disruption for the affected tenant (GitHub Advisory, Fix Commit).

• Logs: OpenBao audit logs showing sys/leases/revoke/<lease_id> requests where the namespace embedded in the lease ID does not match the namespace of the requesting token; unexpected lease revocation events in audit logs for a namespace not initiated by that namespace's own users.
• Network: HTTP PUT/POST requests to /v1/sys/leases/revoke/<lease_id> paths where the lease ID contains a namespace identifier (nsID) different from the caller's namespace.
• Operational: Unexpected expiration or invalidation of dynamic credentials (e.g., database connections dropping, cloud API calls failing with invalid credentials) in a namespace without corresponding revocation activity from that namespace's own administrators.

Upgrade to OpenBao v2.5.5 or later, which contains the fix for this vulnerability (OpenBao Release). Until patching is possible, restrict access to the sys/leases/revoke/:lease_id endpoint to only highly trusted users via ACL policies, and implement monitoring for cross-namespace lease revocation attempts in audit logs. Minimizing the exposure of lease identifiers across namespace boundaries (e.g., through strict logging controls and inter-tenant communication policies) also reduces the attack surface (GitHub Advisory).