The Multitenant Isolation Collapse: Rancher Fleet CVE-2026-41050 Turns Helm Into a Secret Harvester

TL;DR

Rancher Fleet's Helm deployer bypasses ServiceAccount impersonation in two critical code paths, allowing any tenant with git push access to read plaintext secrets from any namespace on every downstream cluster they target. Multi-tenant Kubernetes deployments are now wide open to privilege escalation and credential theft.

What Happened

On May 7, 2026, the SUSE Rancher Security team disclosed CVE-2026-41050 (GHSA-765j-qfrp-hm3j), a critical vulnerability affecting Rancher Fleet versions prior to 0.11.13, 0.12.14, 0.13.10, and 0.14.5. The flaw breaks Fleet's core multi-tenant isolation mechanism by failing to enforce ServiceAccount impersonation across Helm deployment pipelines.

This vulnerability affects organizations running:

• Rancher <= 2.10.11 (requires manual Fleet upgrade)
• Rancher 2.11.x through 2.13.x (requires v2.11.13+ / v2.12.9+ / v2.13.5+)
• Rancher 2.14.0 (requires v2.14.1+)

Patches are now available, but adoption cycles typically lag 30-90 days—meaning most vulnerable deployments remain exposed.

Technical Details: Two Impersonation Bypasses

Bypass #1: The Helm `lookup` Function Retains cluster-admin

When a Helm chart template invokes the lookup function to query Kubernetes resources, Fleet's Helm deployer executes the query using the fleet-agent's cluster-admin credentials instead of the impersonated tenant ServiceAccount.

Attack scenario:

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 }}"

A tenant who controls a Helm chart can exfiltrate any secret from any namespace across all downstream clusters managed by that GitRepo.

Bypass #2: The `fleet.yaml` valuesFrom Directive Ignores Impersonation

When a fleet.yaml file references a Secret or ConfigMap via helm.valuesFrom, the read operation uses cluster-admin privileges rather than the impersonated account. A tenant can craft a fleet.yaml with cross-namespace references like:

helm:
  valuesFrom:
    - secretKeyRef:
        name: "kube-system/admin-token"
        key: "token"

This enables wholesale credential harvesting without RBAC boundaries.

Lyrie Assessment: Why This Matters for Autonomous Defense

The Multi-Tenant Explosion

The proliferation of Kubernetes-as-a-Service (KaaS) and shared-cluster DevOps is accelerating. Enterprises are consolidating workloads to reduce infrastructure costs, but CVE-2026-41050 proves the tenant isolation layer is fundamentally broken at the orchestration level. An autonomous defense system cannot trust tenant boundaries when:

1. Git-to-cluster supply chains are weaponized – A malicious Helm chart or fleet.yaml file is now a direct path to cluster-admin secrets

2. Credential leakage cascades – If a leaked credential belongs to an external service (AWS IAM role, cloud SQL account, API key vault), the attacker gains lateral movement across your entire infrastructure

3. Detection is trivial to bypass – Helm lookups and valuesFrom reads appear as normal workload operations; sidecar-based secret detection cannot distinguish between legitimate and exploit use

The Autonomous Response Requirement

Lyrie's autonomous defense angle: A SIEM or XDR cannot patch this in time. Rancher environments that are multi-tenant and production-critical will remain vulnerable for weeks. Your automated response must:

1. Inventory every Rancher cluster and Fleet-monitored GitRepo

2. Scan for Helm charts containing lookup calls and fleet.yaml files with cross-namespace valuesFrom references

3. Isolate tenants with git push access to monitored repos until patches are staged

4. Rotate any secrets that may have been accessed from namespaces outside the tenant's RBAC scope

5. Monitor for Helm operations against kube-system, default, and other privileged namespaces from tenant-controlled workloads

Defenders without automation will be still writing runbooks by the time exploitation is widespread.

Recommended Actions

Immediate (Next 24 Hours)

1. Identify affected Rancher versions across your estate using:

   kubectl get nodes -A -o wide | grep rancher-version
   rancher-local-cluster: version

Compare against the patch matrix: v2.11.13+, v2.12.9+, v2.13.5+, v2.14.1+

2. Disable Fleet-monitored repositories for untrusted tenants if multi-tenant isolation is critical. Move to single-tenant clusters or enforce strict RBAC on git push access.

3. Audit git repositories for Helm charts using lookup in templates:

   find . -name "*.yaml" -o -name "*.tpl" | xargs grep -l "lookup(" | head -20

4. Inspect fleet.yaml files for cross-namespace valuesFrom references that should fail RBAC:

   find . -name "fleet.yaml" -exec grep -H "helm.valuesFrom" {} \;

Short-term (This Week)

1. Stage patches in pre-production (v2.11.13, v2.12.9, v2.13.5, or v2.14.1).

2. Rotate secrets accessed from kube-system, default, and other privileged namespaces. Assume breach.

3. Enable audit logging on the Kubernetes API server to capture all lookup and secret reads from tenant-controlled pods.

4. Validate GitRepoRestriction resources are deployed to limit which ServiceAccounts each namespace can impersonate (this is a detective control only, not a full mitigation).

Medium-term (Next 30 Days)

1. Roll out patches across all Rancher clusters on a maintenance window.

2. Review and harden Helm chart ownership – require code review for any chart containing lookup functions.

3. Implement network policies to restrict outbound connections from Helm-deployed workloads to credential stores (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault).

4. Consider alternative orchestration models if multi-tenancy is non-negotiable (e.g., virtual clusters, namespace isolation hardening, or migration to single-tenant Kubernetes distributions).

Sources

1. GitHub Advisory Database – GHSA-765j-qfrp-hm3j

2. DailyCVE – Rancher Fleet CVE-2026-41050 Analysis

3. SUSE Rancher Security Policy

---

Lyrie.ai Cyber Research Division