CVE-2026-75035 in Rancher
Summary
by MITRE • 09/03/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified in Rancher Manager represents a critical authorization bypass within the ext.cattle.io/v1 Token store component. This flaw stems from an improper implementation of access control checks when handling label selector queries initiated by non-administrative users. In a properly secured system, such as one adhering to strict Role-Based Access Control principles defined under CWE-269 Improper Privilege Management, the application should validate that the requesting user has permission to view resources associated with other identities. However, in this specific scenario, when a non-administrator supplies a label selector intended to target tokens belonging to a different user, the internal owner filter is erroneously dropped rather than enforcing strict isolation boundaries. This logic error effectively neutralizes the security mechanism designed to restrict data visibility based on ownership, allowing the query to proceed without the necessary restrictions.
The operational impact of this vulnerability is severe due to the sensitive nature of the exposed data. Any authenticated user with access to the Rancher interface can exploit this flaw to list and watch every other user's tokens within the cluster environment. This capability leads directly to CWE-200 Information Exposure, as it allows attackers to enumerate all active authentication credentials for any user in the system. The disclosed information includes not only token metadata but also the stored salted hash of the bearer token itself. While a salted hash is more secure than plaintext storage, its exposure significantly increases the risk profile by providing potential targets with material that could be subjected to offline brute-force or rainbow table attacks if the hashing algorithm has known weaknesses or insufficient entropy. Furthermore, having access to valid token hashes and metadata facilitates lateral movement within the Kubernetes cluster, as attackers can use this information to impersonate other users, escalate privileges, or disrupt service availability by revoking legitimate sessions.
This vulnerability aligns with several techniques documented in the MITRE ATT&CK framework for enterprise environments. Specifically, it relates to T1078 Valid Accounts, where an attacker uses valid credentials obtained through enumeration rather than initial compromise. The ability to list and watch tokens also correlates with T1539 Steal Web Session Cookie, as bearer tokens function similarly to session identifiers in web-based authentication flows. By exploiting this flaw, an adversary can gather intelligence on the identity structure of the organization and map out high-value targets within the infrastructure. This is particularly dangerous in multi-tenant environments where Rancher Manager is used to orchestrate multiple Kubernetes clusters, as compromising one user's token could potentially lead to access across different projects or namespaces if permissions are not strictly segregated at a higher level.
Mitigation for this issue requires immediate application of the vendor-provided patch upgrading Rancher Manager to version 2.15.1 or later, where the internal owner filter logic has been corrected to properly enforce isolation between users regardless of label selector inputs. In addition to applying the software update, organizations should review their existing token policies and consider implementing stricter RBAC roles that limit who can query token resources even before the patch is applied if possible. It is also advisable to rotate all affected bearer tokens immediately after upgrading to ensure that any hashes or metadata potentially harvested by an attacker during the window of vulnerability are invalidated. Regular audits of access logs for unusual patterns in label selector queries should be conducted to detect potential exploitation attempts, and future development processes should include rigorous testing of authorization logic against cross-user resource requests to prevent similar privilege escalation flaws from being introduced into the codebase.