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…

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