Breaking Multi-Tenancy: Deep Dive into the CVE-2026-41050 Fleet Vulnerability

The SUSE Rancher Security team recently disclosed a critical vulnerability, tracked as CVE-2026-41050, which strikes at the very heart of Kubernetes multi-tenancy. This flaw impacts Rancher Fleet, the GitOps engine designed to manage massive Kubernetes fleets through declarative configuration. In a shared environment, the promise of GitOps is scale; the reality of this vulnerability is a complete breakdown of the security boundaries that keep different tenants isolated from one another.

As detailed in a technical deep-dive analysis by Lyrie Threat Intelligence, the flaw effectively weaponizes the Helm deployer, transforming it from a deployment tool into a sophisticated secret-harvesting engine. This allows an attacker to perform unauthorized privilege escalation, potentially moving from a low-privilege tenant to full cluster-admin status.

The Mechanics of the Failure: Broken Impersonation

At its technical core, the vulnerability stems from a failure in ServiceAccount impersonation. In a secure GitOps workflow, when Fleet deploys a workload on behalf of a user, it should assume the identity and limited permissions of that specific user. However, Fleet’s Helm deployer fails to enforce this boundary, executing certain operations using the highly privileged credentials of the fleet-agent instead of the restricted tenant account.

This oversight creates two distinct exploitation vectors:

1. The Helm lookup Function Bypass

The first vector exploits the standard Helm template engine. An attacker with “git push” access to a monitored repository can craft a malicious Helm chart. By utilizing the lookup function, the chart can query the Kubernetes API for resources it should never see.

apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
  name: tenant-chart
  namespace: tenant-ns
spec:
  repo: https://github.com/tenant/malicious-chart
  helm:
    values:
      # The following line instructs Fleet to grab a system-level token
      adminToken: "{{ lookup('v1', 'Secret', 'kube-system', 'admin-secret').data.token }}"

Because Fleet executes this lookup with the identity of the fleet-agent, it can successfully reach into the kube-system namespace, grab a cluster-admin token, and leak it back into the tenant’s deployment metadata.

2. The valuesFrom Configuration Bypass

The second vector resides within the FleetFleet.yaml configuration. When a user defines a valuesFrom directive to pull data from a Secret or ConfigMap, the system performs the read operation. Due to the impersonation flaw, the system performs this read with cluster-admin privileges rather than checking if the tenant has permission to access that specific object.

This is particularly dangerous because these reads appear as legitimate, automated workload operations. To a standard Kubernetes Audit Log, the activity looks like normal Fleet behavior, making detection an uphill battle for security operations centers (SOCs).

Scope of Impact and Remediation

This is not merely a theoretical risk; it is a catastrophic threat to Kubernetes-as-a-Service (KaaS) providers. If an attacker extracts an AWS IAM role or a cloud provider credential from a cluster secret, the blast radius extends far beyond the Kubernetes cluster and into the entire corporate cloud infrastructure.

Affected Versions:

• Rancher Fleet: All versions prior to 0.11.13, 0.12.14, 0.13.10, and 0.14.5.
• Rancher 2.10.x: Versions 2.10.11 and older (Note: These require a manual Fleet upgrade).
• Rancher 2.11.x – 2.13.x: Vulnerable until updated to 2.11.13, 2.12.9, or 2.13.5 respectively.
• Rancher 2.14.0: Vulnerable until updated to 2.14.1.

Incident Response and Mitigation Strategy

While patching is the only permanent resolution, security teams must act immediately to contain potential exploitation. We recommend the following tactical steps:

1. Isolate Untrusted Tenants: Immediately disable Fleet-monitored repositories for any third-party or untrusted tenants until your environment is patched.
2. Proactive Code Audit: Scan your Git repositories for any Helm templates utilizing the lookup function. Simultaneously, audit all FleetFleet.yaml files for valuesFrom references that point to namespaces outside the tenant’s scope.
3. Assume Breach & Rotate: If you find unauthorized lookup calls or cross-namespace references, treat the environment as compromised. Immediately rotate all secrets in privileged namespaces, specifically kube-system and any namespaces containing cloud provider credentials.
4. Enhance Observability: Tighten your Kubernetes API audit logging. Specifically, monitor for get and list requests on Secrets originating from the Fleet controller that deviate from established baseline patterns.