Description

OpenBao is an open source identity-based secrets management system. Prior to version 2.5.4, in OpenBao's Kerberos auth method on the `GET` handler, or when an `Authorization: Negotiate` header is supplied, the response is includes a `logical.Auth` object in addition to an error message. This results in tokens being created with only the default policy, default TTL, and no entity information, which are hidden by the returned error message. No access to these tokens by the caller occurs and the authentication token is not ever made accessible outside of `sys/raw`. This is fixed in OpenBao v2.5.4. As a workaround, users may set a rate limit quota to limit the creation of these paths. As the path is unauthenticated, it isn't possible to deny access to it.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.3",
  "pubDate": "2026-08-07T22:16:58.600Z",
  "pubdate": "2026-08-07T22:16:58.600Z",
  "executiveSummary": "OpenBao prior to version 2.5.4 suffers from an information handling flaw within the Kerberos authentication method. When utilizing the GET handler or supplying an Authorization: Negotiate header, the system erroneously includes a logical.Auth object alongside the returned error message.\nThis behavior leads to the unintended creation of internal authentication tokens when processing unauthenticated requests. Although these tokens are restricted to the default policy and default TTL, contain no entity information, and are obscured by the accompanying error message without direct retrieval by the caller, the underlying token creation represents an unintended state change and resource allocation within the secrets management system.\nThe vulnerability impacts the Kerberos auth method across unauthenticated endpoints. Attackers do not require prior authentication or privileged access to trigger the condition, as the targeted paths are exposed without access control enforcement. While the generated tokens are not explicitly returned in the payload or accessible outside of sys/raw, repeated triggering of this flaw leads to unauthenticated token accumulation.\nRisk implications center on unintended resource consumption and state pollution within the authentication subsystem. Mitigation requires upgrading to the patched version or implementing compensating controls such as rate limit quotas to restrict the velocity of requests hitting the vulnerable paths.",
  "technicalDetails": "The vulnerability resides in the Kerberos authentication method component of OpenBao, specifically within the request handling logic for the GET method and when processing the Authorization: Negotiate HTTP header. The vulnerable component fails to properly isolate error states from authentication state generation during failed or malformed negotiation sequences.\nThe root cause stems from improper error handling and response construction within the authentication pipeline. When an unauthenticated request hits the Kerberos auth method handler under the specified conditions, the application attempts to process the negotiation header. Due to flawed logic, the execution flow generates a logical.Auth object even when an error condition is encountered and returned to the client.\nThe step-by-step attack flow proceeds as follows: First, an unauthenticated attacker sends an HTTP request targeting the Kerberos auth method endpoint utilizing the GET method or incorporating a crafted Authorization: Negotiate header. Second, the OpenBao server processes the request through the vulnerable component. Third, while the server ultimately denies the request and returns an error message to the client, the internal execution path improperly completes a token creation sequence, resulting in the generation of a valid token instance.\nThe resulting tokens are instantiated with minimal privileges, specifically restricted to the default policy, default TTL, and lacking any associated entity information. These tokens remain hidden behind the returned error message, meaning the caller receives no direct output containing the token material. Furthermore, the authentication tokens are never made accessible outside of sys/raw, preventing direct exfiltration via the standard API response.\nRegarding environmental requirements, the vulnerability affects OpenBao versions prior to v2.5.4. No authentication requirements or privilege requirements exist for the initiator, as the affected paths are inherently unauthenticated, making it impossible to deny access to the endpoint via standard access control policies. Network exposure includes any interface exposing the OpenBao API where the Kerberos auth method is enabled. The payload behavior involves standard HTTP protocol interactions utilizing the Negotiate mechanism, driving the server into the flawed execution path."
}