Description

A flaw was found in Rancher Manager. When a non-administrative caller supplied a label selector naming a different user, the ext.cattle.io/v1 Token store dropped its internal owner filter instead of returning an empty result. Any authenticated user could therefore list and watch every other user's tokens, disclosing token metadata and the stored salted hash of the bearer token. This issue affects Rancher: before 2.15.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.7",
  "pubDate": "2026-09-03T16:18:22.477Z",
  "pubdate": "2026-09-03T16:18:22.477Z",
  "executiveSummary": "This vulnerability is an Improper Authorization flaw identified in the Rancher Manager ext.cattle.io/v1 Token store. The issue arises due to a failure in the API's filtering logic when processing specific label selectors.\nWhen a non-administrative user submits a request with a label selector targeting another user's resources, the backend incorrectly drops the mandatory internal owner filter. This oversight permits the unauthorized disclosure of sensitive token metadata, including the salted hash of bearer tokens, for any user within the system.\nThe vulnerability affects Rancher versions prior to 2.15.1. Impact is severe, as it allows any authenticated attacker to enumerate and inspect tokens belonging to other users, potentially leading to full account takeover or privilege escalation depending on the sensitivity of the exposed tokens.\nExploitation requires the attacker to hold a valid authenticated session within the Rancher environment but does not require administrative privileges. By crafting a specific API request, an attacker can bypass access control mechanisms and circumvent resource isolation boundaries, posing a significant risk to the integrity and confidentiality of the entire managed Kubernetes environment.",
  "technicalDetails": "The root cause of this vulnerability lies in the implementation of the request filtering mechanism within the ext.cattle.io/v1 Token store in Rancher Manager. Under normal operating conditions, the store is designed to enforce an internal owner filter to ensure that users can only interact with tokens associated with their own identity.\nThe flaw is triggered when a user performs a list or watch operation on the Token resource while supplying a label selector that explicitly references a different user. Instead of returning an empty result or a 403 Forbidden status, the API logic incorrectly interprets the presence of the custom label selector as a reason to override or drop the pre-configured owner filter.\nThe attack flow proceeds as follows: 1) An authenticated user initiates an HTTP request to the Rancher API endpoint responsible for listing tokens. 2) The attacker appends a label selector query parameter (e.g., selector=auth.cattle.io/user-id=<Target_User_ID>) to the request. 3) The backend API handler fails to reconcile the user's implicit permissions with the explicit selector provided by the client. 4) The server logic discards the internal ownership restriction, causing the store to query all available token objects rather than the subset restricted to the requester. 5) The API returns a JSON response containing the full metadata and the stored salted hash of the bearer tokens for the specified target user.\nThis vulnerability is critical because it bypasses the multi-tenancy isolation provided by the Token store. The disclosure of the salted hash of bearer tokens allows an attacker to perform offline brute-force or dictionary attacks against the hashes to recover plaintext bearer tokens, effectively compromising the target's authentication credentials. Because Rancher manages broad clusters, an attacker could potentially escalate privileges to cluster administrator if the intercepted tokens possess high-level permissions.\nThe vulnerability is present in versions of Rancher prior to 2.15.1 and affects the core API layer governing token management. As this occurs at the controller level of the Rancher Manager, the exposure is internal to the API server and does not necessarily require network-level access if the attacker already has a session token. No administrative privilege is required to trigger this flawed logic; standard authentication is the only prerequisite."
}