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.
A flaw was found in Rancher Manager. The SAML assertion replay protection introduced by the fix for CVE-2026-44946 recorded consumed assertion IDs in a per-process cache, so each replica only detected replays that reached the same pod. In a high-availability deployment, an attacker holding a captured assertion could replay it once against every other replica to obtain additional authenticated sessions as the victim.
This issue affects Rancher: before 2.15.1.
A flaw was found in Rancher Manager. The /v3/users update path did not enforce immutability of a User resource's `username` and `principalIds` fields. A user holding the `update` verb on `users.management.cattle.io` could inject a foreign identity provider principal into any account, so that the next login by the owner of that principal was bound to the victim's account and inherited its role bindings.
This issue affects Rancher: before 2.15.1.
A flaw was found in Rancher Manager. The GlobalRole controller derived the target ClusterRole name from the user-settable `authz.management.cattle.io/cr-name` annotation and overwrote that object's rules without verifying ownership. A user with delegated GlobalRole create or update permission could point the annotation at any existing ClusterRole, such as `cluster-admin`, and revoke the permissions of every principal bound to it. The change persists after the malicious GlobalRole is deleted.
This issue affects Rancher: before 2.15.1.
A flaw was found in Rancher Manager. Project Secrets were propagated into a namespace based only on its `field.cattle.io/projectId` annotation, without verifying that the referenced project belonged to the same downstream cluster. A user able to create namespaces on one cluster could set the annotation to a project ID from another cluster and have that project's secrets copied into a namespace under their control.
This issue affects Rancher: before 2.15.1.
A vulnerability has been identified which may lead to sensitive data being leaked into Rancher's audit logs. [Rancher Audit Logging](https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-api-audit-log) is an opt-in feature, only deployments that have it enabled and have [AUDIT_LEVEL](https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/enable-api-audit-log#audit-log-levels) set to `1 or above` are impacted by this issue.
In Rancher 2.x before 2.6.13 and 2.7.x before 2.7.4, an incorrectly applied authorization check allows users who have certain access to a namespace to move that namespace to a different project.
An Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in SUSE Rancher allows users in some higher-privileged groups to to inject code that is
executed within another user's browser, allowing the attacker to steal
sensitive information, manipulate web content, or perform other
malicious activities on behalf of the victims. This could result in a
user with write access to the affected areas being able to act on behalf
of an administrator, once an administrator opens the affected web page.
This issue affects Rancher: from >= 2.6.0 before < 2.6.13, from >= 2.7.0 before < 2.7.4.
An Improper Privilege Management vulnerability in SUSE Rancher allowed standard users to leverage their existing permissions to manipulate Kubernetes secrets in the local
cluster, resulting in the secret being deleted, but their read-level
permissions to the secret being preserved. When this operation was
followed-up by other specially crafted commands, it could result in the
user gaining access to tokens belonging to service accounts in the local cluster.
This issue affects Rancher: from >= 2.6.0 before < 2.6.13, from >= 2.7.0 before < 2.7.4.
A Improper Privilege Management vulnerability in SUSE Rancher causes permission changes in Azure AD not to be reflected to users
while they are logged in the Rancher UI. This would cause the users to
retain their previous permissions in Rancher, even if they change groups
on Azure AD, for example, to a lower privileged group, or are removed
from a group, thus retaining their access to Rancher instead of losing
it.
This issue affects Rancher: from >= 2.6.7 before < 2.6.13, from >= 2.7.0 before < 2.7.4.