CVE-2026-46405: 
Wolfi 脆弱性の分析と軽減

CVE-2026-46405 is a resource exhaustion vulnerability in OpenBao's Kerberos authentication method that allows unauthenticated remote attackers to cause unbounded token accumulation in storage. When the Kerberos auth method's GET handler is accessed, or when an Authorization: Negotiate header is supplied, the response incorrectly includes a logical.Auth object alongside an error message, causing tokens to be silently created with only the default policy, default TTL, and no entity information. Affected versions are OpenBao ≤ 2.5.3 (Go module github.com/openbao/openbao). The vulnerability was published on May 21, 2026, and has a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory, OpenBao Advisory).

The root cause is classified as CWE-770 (Allocation of Resources Without Limits or Throttling). In the Kerberos auth plugin's pathLoginGet handler (builtin/credential/kerberos/path_login.go), the function returned a logical.Response containing an empty &logical.Auth{} object simultaneously with a non-nil error. OpenBao's core request handling logic in vault/request_handling.go did not previously check for this condition, so it proceeded to generate a token even when the backend returned an error — the token was never delivered to the caller but was persisted in storage. The fix (PR #3150) removes the erroneous Auth: &logical.Auth{} from the GET handler and adds a guard in the core request handler to nil out resp.Auth whenever routeErr is non-nil, preventing token creation on error paths. A Semgrep rule was also added to detect this anti-pattern in future code (GitHub Commit, GitHub Advisory).

The primary impact is an availability degradation through excessive storage consumption: repeated unauthenticated requests to the Kerberos auth endpoint cause orphaned tokens to accumulate in OpenBao's storage backend, which can degrade performance or exhaust storage capacity over time. There is no confidentiality or integrity impact — the created tokens carry only the default policy, have no entity information, and are never returned to the caller; they are inaccessible outside of sys/raw. No lateral movement or data exposure risk has been identified (GitHub Advisory, OpenBao Advisory).

No public proof-of-concept exploit code is known, and there is no evidence of in-the-wild exploitation at this time. The vulnerability is trivially triggerable by any unauthenticated network attacker — no credentials or special conditions are required beyond sending a GET request or an Authorization: Negotiate header to the Kerberos auth endpoint. The CVE is not listed in the CISA Known Exploited Vulnerabilities catalog, and no threat actor attribution has been reported (GitHub Advisory).

1. Reconnaissance: Identify OpenBao instances running version ≤ 2.5.3 with the Kerberos auth method enabled and mounted (e.g., at auth/kerberos/login).
2. Send unauthenticated GET request: Issue a GET request to the Kerberos login endpoint (e.g., GET /v1/auth/kerberos/login) without any credentials, or include an Authorization: Negotiate header with an arbitrary value.
3. Trigger token creation: The pathLoginGet handler returns a logical.Response with an empty logical.Auth{} object alongside an error; the core request handler (in vulnerable versions) proceeds to create a token in storage.
4. Repeat to exhaust storage: Automate the request in a loop to continuously generate orphaned tokens, accumulating storage usage and potentially degrading OpenBao availability over time (GitHub Commit, GitHub Advisory).

• Network: High volume of unauthenticated GET requests or requests with Authorization: Negotiate headers to the Kerberos auth login endpoint (e.g., /v1/auth/kerberos/login) from a single or rotating source IP.
• Logs: OpenBao audit logs showing repeated failed Kerberos authentication attempts (error responses) at the login path with no corresponding successful authentications.
• Storage: Abnormal growth in OpenBao's storage backend (e.g., Raft, Consul, etcd) with a large number of token entries under the token store path, particularly tokens with only the default policy and no entity association.
• Metrics: Elevated token creation counters in OpenBao telemetry without a corresponding increase in successful logins or active sessions.

Upgrade to OpenBao v2.5.4 or later, which removes the erroneous logical.Auth{} return from the Kerberos GET handler and adds a core-level guard preventing token creation when an error is also returned (OpenBao Release). As a temporary workaround for organizations unable to upgrade immediately, configure a rate limit quota on the Kerberos auth path to throttle the rate of token creation; note that because the endpoint is unauthenticated, access cannot be fully denied through standard authorization controls (GitHub Advisory).

The vulnerability was discovered by an anonymous reporter and fixed by OpenBao maintainer Alexander Scheel (cipherboy), who also added a Semgrep static analysis rule to prevent recurrence of the same anti-pattern in future code. The fix was backported to the 2.5.x release branch and included in the v2.5.4 security release alongside two other CVEs. Coverage has appeared in Linux distribution security update channels (e.g., Fedora) and security scanning tools such as Tenable Nessus (OpenBao Release, GitHub PR).