critical · 9.9CVE-2026-44935Jul 1, 2026

CVE-2026-44935: Rancher Fleet Cross-Namespace Secret Disclosure via Unvalidated valuesFrom

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

A flaw in Rancher Fleet lets any tenant read Kubernetes secrets from other namespaces on a shared downstream cluster, by pointing the valuesFrom field in a fleet.yaml or HelmOp resource at an arbitrar

Packagegithub.com/rancher/fleet
Ecosystemgo
Affected>= 0.15.0, < 0.15.2
Fixed in0.15.2

The problem

Fleet's Helm deployer honored `valuesFrom` references in `fleet.yaml` (via a `GitRepo`) and in `HelmOp` resources without checking whether the requesting tenant had permission to read the referenced secret or configmap. Because the namespace field in a `secretKeyRef` or `configMapKeyRef` was never validated against the tenant's allowed namespaces, any tenant with access to create a `GitRepo` or `HelmOp` could freely name any namespace on the downstream cluster.

The same authorization gap let tenants deploy `HelmOp` and `Bundle` resources without being bound to a specific service account for the Fleet agent, effectively inheriting the agent's elevated permissions. In a multi-tenant shared cluster, this means a lower-privileged team could read credentials, kubeconfigs, or certificates owned by other teams.

Proof of concept

A working proof-of-concept for CVE-2026-44935 in github.com/rancher/fleet, with the exact payload below.

text
# fleet.yaml committed to an attacker-controlled GitRepo
# Reads the contents of kube-system/bootstrap-token-abcdef (any secret)
# across namespace boundaries, with no prior authorization required.
helm:
  chart: ./dummy-chart
  releaseName: exfil
  valuesFrom:
    - secretKeyRef:
        name: bootstrap-token-abcdef   # target secret name (guessed or enumerated)
        namespace: kube-system         # any namespace on the downstream cluster
        key: token-secret              # key whose value ends up in Helm values

The root cause (CWE-863, Incorrect Authorization) is that the Fleet controller, when resolving `valuesFrom` entries for a bundle deployment, called the Kubernetes API to fetch the referenced secret or configmap using the Fleet agent's own service account, not the tenant's.

There was no check that the `namespace` field in a `secretKeyRef` or `configMapKeyRef` matched the namespace the tenant was authorized to operate in.

The patch introduces a `Policy` CRD (replacing the narrower `GitRepoRestriction`) that an admin must create in each tenant namespace. The Policy can mandate a specific downstream service account for the Fleet agent and can restrict `HelmOp` repository URLs via a fully-anchored regular expression, closing both the secret-disclosure and the unrestricted-deploy paths.

The fix

Upgrade Fleet to v0.15.2 (or v0.14.6, v0.13.11, v0.12.15 for older branches). After upgrading, create a `Policy` resource in each tenant namespace specifying the least-privilege service account the Fleet agent must impersonate on downstream clusters. If immediate upgrade is not possible, ensure tenants do not share any downstream cluster.

Reported by Radisauskas Arnoldas (NATO / NATO Cyber Security Centre, NCSC).

References: [1][2]

Related research