A critical vulnerability in SUSE’s Rancher Fleet has been disclosed by the SUSE Rancher Security team, threatening the multi-tenant isolation that shared Kubernetes environments depend on.
Tracked as CVE-2026-41050, the flaw allows authenticated tenants to escalate privileges to full cluster-admin status and silently harvest secrets across downstream clusters, making it an urgent concern for any organization running Rancher in a shared DevOps or Kubernetes-as-a-Service environment.
According to analysis by Lyrie Threat Intelligence, the root cause lies in Fleet’s Helm deployer failing to enforce ServiceAccount impersonation across deployment pipelines.
Instead of executing Helm operations under a restricted tenant account, Fleet runs them using its highly privileged fleet-agent credentials. This single oversight opens two distinct avenues for exploitation.
The first pathway abuses the Helm lookup function. A malicious tenant with basic “git push” access to a monitored repository can craft a chart template that queries Kubernetes secrets using the lookup function.
Because Fleet executes that lookup as fleet-agent rather than the tenant’s restricted account, attackers can extract admin tokens from any namespace, including kube-system across all downstream clusters. A proof-of-concept configuration demonstrates how trivially this can be achieved:
apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
name: tenant-chart
namespace: tenant-ns
spec:
repo: https://github.com/tenant/malicious-chart
helm:
values:
adminToken: "{{ lookup('v1', 'Secret', 'kube-system', 'admin-secret').data.token }}"The second pathway exploits the valuesFrom directive inside fleet.yaml configuration files. When this directive references a Secret or ConfigMap, Fleet reads the data with cluster-admin privileges, allowing attackers to target credentials outside their permitted namespace.
Crucially, because these unauthorized reads resemble normal workload operations, standard security monitoring tools cannot easily distinguish them from legitimate activity.
Affected Versions
The vulnerability impacts a wide range of Rancher and Rancher Fleet releases. Rancher Fleet versions before 0.11.13, 0.12.14, 0.13.10, and 0.14.5 are all vulnerable.
For full Rancher deployments, Rancher 2.10.11 and older are affected and require a manual Fleet upgrade. Rancher branches 2.11.x, 2.12.x, and 2.13.x remain vulnerable until updated to versions 2.11.13, 2.12.9, and 2.13.5 respectively. Rancher 2.14.0 users must upgrade to version 2.14.1 immediately.
The risk extends beyond Kubernetes itself. If stolen credentials belong to an external service, such as an AWS IAM role, attackers can use them to pivot laterally across an organization’s entire cloud infrastructure.
Mitigation
Patching to the fixed versions remains the definitive remediation. However, security teams should take several autonomous actions while updates are staged across their environments.
Start by auditing all Fleet-monitored repositories and immediately restricting access for any untrusted tenants. Scan Helm chart templates for use of the lookup function and review all fleet.yaml files for cross-namespace valuesFrom references.
Any unauthorized lookups discovered during this audit should be treated as indicators of compromise. Rotate all secrets accessible from privileged namespaces, particularly kube-system, without delay.
Finally, enable strict audit logging on the Kubernetes API server to capture all future secret read operations originating from tenant-controlled pods, establishing a baseline for detecting ongoing exploitation attempts.
No Comment! Be the first one.