CVE-2026-41050: Rancher Fleet Flaw Exposes Kubernetes Secrets

A critical ServiceAccount impersonation bypass in Rancher Fleet (CVSS 9.9) allows any tenant with git push access to silently read plaintext secrets from every namespace across all downstream Kubernetes clusters, breaking multi-tenant isolation at its core.

On May 7, 2026, CVE-2026-41050 (tracked as GHSA-765j-qfrp-hm3j), a critical vulnerability carrying a CVSS v3.1 score of 9.9 (Critical). The flaw resides in Rancher Fleet’s Helm deployer, which fails to fully enforce ServiceAccount impersonation across two distinct code paths, the Helm lookup function and the valuesFrom directive in fleet.yaml files.

Any tenant who has git push access to a Fleet-monitored repository can exploit either path to harvest secrets from namespaces they have no legitimate RBAC access to, across every downstream cluster targeted by their GitRepo resource.

The vulnerability affects Rancher Fleet versions before 0.11.13, 0.12.14, 0.13.10, and 0.14.5. Organizations running Rancher ≤ 2.10.11 must manually upgrade their Fleet deployment to v0.11.13, while those on Rancher 2.11.x through 2.14.x must upgrade to the corresponding patched versions v2.11.13+, v2.12.9+, v2.13.5+, or v2.14.1+.

Critically, no workaround fully closes the vulnerability in multi-tenant environments; the SUSE advisory explicitly states the patches must be applied as soon as possible.

CVE-2026-41050: Rancher Fleet Vulnerability

Fleet’s architecture is designed so that each tenant’s Helm deployment runs under an impersonated ServiceAccount, enforcing RBAC boundaries and preventing cross-namespace access. CVE-2026-41050 breaks this design at two specific Helm pipeline stages, each of which is independently exploitable.

Bypass 1 – Helm lookup Function Retains cluster-admin Privileges

When a Helm chart template invokes the lookup When querying the Kubernetes API for resources, the Fleet deployer executes the query using the fleet-agent’s cluster-admin credentials rather than the scoped, impersonated tenant ServiceAccount. A malicious tenant can craft a GitRepo-backed Helm chart containing a template like:

adminToken: "{{ lookup('v1', 'Secret', 'kube-system', 'admin-secret').data.token }}"

This single template line is enough to silently exfiltrate any secret from any namespace, including kube-system across all downstream clusters targeted by that GitRepo, with no RBAC violation logged against the tenant. The attack requires only a commit to a Fleet-monitored repository.

Bypass 2 – valuesFrom Directive in fleet.yaml Ignores Impersonation

The second bypass occurs when a fleet.yaml file references a Secret or ConfigMap via the helm.valuesFrom directive. This read operation also uses the fleet-agent’s cluster-admin client instead of the impersonated account. An attacker can configure a cross-namespace reference, such as:

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

Because valuesFrom reads bypass RBAC enforcement entirely, a tenant can perform wholesale credential harvesting from privileged namespaces without triggering RBAC denial events. Both bypasses have now been fixed by ensuring the Helm action configuration consistently uses impersonated ServiceAccount credentials throughout all Helm operations.

The severity of CVE-2026-41050 is magnified by modern enterprise adoption of Kubernetes. Organizations increasingly run shared-cluster DevOps platforms, Kubernetes-as-a-Service environments, where multiple development teams or business units share the same downstream clusters via Fleet’s GitOps pipelines.

In these architectures, tenant isolation is not just a security posture; it is the fundamental trust contract that makes shared infrastructure viable. The CVSS vector AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H reflects the full scope of impact: network-accessible, low-complexity, requiring only low-level privileges (a git commit), with a scope change that crosses cluster trust boundaries.

When leaked credentials belong to external services, AWS IAM roles, Azure Key Vault tokens, HashiCorp Vault root tokens, or database connection strings, the impact extends well beyond Kubernetes into the organization’s entire cloud infrastructure.

A single malicious chart commit can trigger a lateral movement chain that compromises every connected cloud account, according to the Lyrie team.

Detection is also non-trivial: Helm lookup calls and valuesFrom reads appear as ordinary workload operations inside audit logs, making them nearly indistinguishable from legitimate deployment activity without purpose-built behavioral analytics.

Patch and Mitigation

Security teams should prioritize the following actions in order of urgency:

1. Audit Helm charts immediately – Scan all Fleet-monitored GitRepo chart templates for any use of the lookup function using: find . -name "*.yaml" -o -name "*.tpl" | xargs grep -l "lookup("
2. Inspect fleet.yaml files for cross-namespace valuesFrom references that exceed the tenant’s RBAC scope.
3. Restrict git push access to Fleet-monitored repositories to trusted users only, eliminating the precondition for exploitation in the interim.
4. Deploy GitRepoRestriction resources to limit which ServiceAccounts each namespace may impersonate. This is a detective control only, not a full mitigation.
5. Stage and apply patches – Begin rollout of v2.11.13, v2.12.9, v2.13.5, or v2.14.1 in pre-production immediately, then push to production within your next maintenance window.
6. Rotate exposed secrets – Assume any secrets in kube-system, default, and other privileged namespaces may have been accessed. Rotate credentials and treat affected clusters as compromised until patched.
7. Enable Kubernetes API audit logging to capture all secret read events from tenant-controlled pods for forensic review.

FAQ

Q1: Does CVE-2026-41050 affect single-tenant Rancher Fleet deployments?

No, single-tenant deployments where all users are fully trusted are not affected by this vulnerability, as the impersonation boundary only matters when untrusted tenants share downstream clusters.

Q2: Is there a working workaround if patching immediately isn’t possible?

No workaround fully closes the vulnerability in multi-tenant environments; SUSE’s advisory explicitly states that patches must be applied, though restricting git push access and deploying GitRepoRestriction resources reduces the attack surface.

Q3: Can existing security tools like SIEMs detect active exploitation of this flaw?

Exploitation is extremely difficult to detect because Helm lookup calls and valuesFrom Reads appear as normal workload activity in logs. Purpose-built behavioral analytics or dedicated Kubernetes audit monitoring are required.

Q4: Which Fleet versions contain the fix for CVE-2026-41050?

The fix is present in Fleet versions 0.11.13, 0.12.14, 0.13.10, and 0.14.5, with corresponding Rancher releases v2.11.13, v2.12.9, v2.13.5, and v2.14.1.

Site: thecybrdef.com

For more insights and updates, follow us on Google News, Twitter, and LinkedIn.

About the Author

John

Author

John is an independent cybersecurity researcher covering vulnerabilities, malware campaigns, and emerging threats in the cybersecurity landscape.

Visit Website View All Posts