CVE-2026-46405: 
Wolfi vulnerability analysis and mitigation

CVE-2026-46405 is a Denial of Service vulnerability in OpenBao's Kerberos authentication method that allows unauthenticated network attackers to trigger unbounded token creation, consuming storage resources. Discovered by an anonymous reporter and published on May 21, 2026, it affects all OpenBao versions up to and including 2.5.3 (Go module github.com/openbao/openbao). The flaw was fixed in OpenBao v2.5.4, released May 20, 2026. It carries a CVSS v3.1 base score of 5.3 (Medium) (Github Advisory).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): the Kerberos auth method's GET handler (and any request supplying an Authorization: Negotiate header) incorrectly returned a logical.Auth{} object alongside an error response. OpenBao's core request handling logic interpreted the non-nil Auth field as a successful authentication and proceeded to create a token with only the default policy, default TTL, and no entity information — even though the error message was returned to the caller and the token was never exposed outside sys/raw. The fix, applied in PR #3150 (commit 0d82e0a), nullifies resp.Auth whenever a non-nil error accompanies an auth response, and adds a Semgrep rule to prevent recurrence of this pattern (Github Advisory, Fix PR, Fix Commit).

The primary impact is availability degradation through excessive storage consumption: each unauthenticated request to the Kerberos auth endpoint causes an orphaned token to be written to OpenBao's storage backend. Over time, high-volume requests can exhaust storage capacity and degrade service availability. There is no confidentiality or integrity impact — the created tokens are inaccessible to the caller and cannot be retrieved outside of sys/raw, so no unauthorized access to secrets or lateral movement is possible (Github Advisory).

No public proof-of-concept exploit exists and no in-the-wild exploitation has been observed (Github Advisory). The vulnerability is automatable (no authentication or user interaction required), making it straightforward to trigger at scale via repeated HTTP GET requests or requests with an Authorization: Negotiate header. The EPSS score is approximately 0.083–0.364%, placing it in the lower percentiles for near-term exploitation likelihood. It is not listed in the CISA Known Exploited Vulnerabilities catalog. No threat actor attribution is available.

1. Reconnaissance: Identify internet-facing or network-accessible OpenBao instances running versions ≤ 2.5.3 with the Kerberos auth method enabled (e.g., by scanning for OpenBao API endpoints).
2. Send crafted requests: Issue repeated HTTP GET requests to the Kerberos auth login endpoint (e.g., /v1/auth/kerberos/login) or include an Authorization: Negotiate header in requests to that path — no valid Kerberos ticket is required.
3. Trigger orphaned token creation: Each such request causes OpenBao's core to create a token with default policy and TTL, writing it to storage without returning it to the caller.
4. Exhaust storage: By automating a high volume of such requests, an attacker accumulates orphaned tokens in storage, potentially exhausting available storage capacity and degrading or denying service to legitimate users (Github Advisory, Fix PR).

• Network: Unusually high volume of HTTP GET requests or requests with Authorization: Negotiate headers to the Kerberos auth endpoint (e.g., /v1/auth/kerberos/login) from one or more source IPs.
• Logs: OpenBao audit logs showing repeated unauthenticated requests to the Kerberos login path returning errors, with no corresponding successful authentications.
• Storage: Rapid, unexplained growth in OpenBao's storage backend (e.g., Raft, Consul, PostgreSQL) due to accumulation of orphaned token entries; tokens visible only via sys/raw with default policy and no entity information.
• Metrics: Elevated token creation counters in OpenBao telemetry without a corresponding increase in active authenticated sessions.

Upgrade to OpenBao v2.5.4 or later, which nullifies the Auth response object whenever a non-nil error is also returned, preventing orphaned token creation (OpenBao Release). As a temporary workaround for those unable to upgrade immediately, configure a rate limit quota on the Kerberos auth path to throttle the rate of requests and limit storage consumption. Note that because the endpoint is unauthenticated, it cannot be blocked via standard authorization policies — network-level controls (e.g., firewall rules restricting access to the OpenBao API) should also be considered to reduce exposure (Github Advisory).

The fix was authored by OpenBao core contributor Alexander Scheel (cipherboy) and merged promptly on May 20, 2026, the same day the advisory was published, indicating a coordinated disclosure process. The release notes for v2.5.4 highlight the fix alongside two other security issues, suggesting a bundled security release. Coverage has been limited to automated vulnerability tracking services and Linux distribution security advisories (e.g., Fedora, FreeBSD ports), with no notable independent researcher commentary or broad media coverage (OpenBao Release).