The Rancher Manager meta proxy did not consistently remove the caller's Rancher credentials from requests forwarded to third-party cloud provider hosts. A signed-in user's browser session or a non-browser client's Rancher API token can therefore be sent to a host on the proxy's allow-list, for example during ordinary use of cloud provisioning forms. Anyone who can operate or observe that host, including through its logs, can obtain a live credential with the affected user's permissions, which may include administrative access to the Rancher control plane and the managed clusters.
SUSE · Rancher Manager
SUSE Rancher Manager does not validate the inheritedNamespacedRules field of a GlobalRole for privilege escalation. An authenticated user who is already allowed to create or update GlobalRoles and create GlobalRoleBindings can obtain permissions in named namespaces of all downstream clusters that exceed their own permissions. Per the vendor, administrators are expected to hold these permissions, so this is not an escalation for them. The impact on confidentiality, integrity and availability is limited to the affected namespaces, but it spans every managed downstream cluster.
SUSE · Rancher Manager
Rancher Fleet's agent management controller did not sufficiently restrict which kubeconfig secrets a Fleet Cluster object may reference. An authenticated user who can create a Fleet cluster in a namespace they control can associate it with the administrative credentials of the Rancher management (local) cluster. The controller then manages that cluster and runs the user's Fleet content there with elevated privileges, which can lead to full cluster-admin access, exposure of stored secrets including downstream cluster credentials, and disruption of the Rancher management server.
SUSE · Rancher Fleet
The /meta/proxy endpoint of SUSE Rancher Manager evaluates its destination allowlist in a place where it cannot stop forwarding, so rejected requests are still sent. An authenticated Rancher user can make the Rancher server send requests to internal services and, in some environments, to the cloud instance metadata endpoint, and read the responses. Exploitation requires an HTTP/1.1 request with a full destination URL that reaches Rancher without an HTTP-aware proxy rewriting it, which the default Helm ingress usually blocks but other exposure paths do not.
SUSE · Rancher Manager
Fleet, the GitOps component of SUSE Rancher, accepted the cluster identity claimed in a registration request without binding it to the registration token used. An attacker holding a valid registration token for a Fleet workspace and knowing the client identifier of another cluster in that workspace can obtain credentials for that cluster's Fleet management namespace. This can expose Secrets and ConfigMaps synced there, allow limited changes to status information, and disrupt Fleet management of the affected cluster. Cross-tenant impact is possible where clusters of different tenants share one workspace.
SUSE · Rancher Fleet
The sdbootutil script of SUSE Linux Enterprise Server, openSUSE Leap and openSUSE Tumbleweed creates a debug log at /var/log/sdbootutil.log that is world-readable when it is requested. Any local user with a low-privileged account can read the log and may extract secrets from it. The attacker needs local access and the log must have been created, so the exposure is limited to affected hosts with the systemd-boot setup.
SUSE · sdbootutil
Rancher stores project-related resources in a namespace named after the project, so two projects with the same name on different clusters share that namespace. A user who can create projects on one cluster can create a project with the same name as a project on another cluster and thereby gain access to that project. The attack requires an authenticated account with project-creation rights on at least one cluster.
SUSE · Rancher
