GitHub Security Advisory: GHSA-765j-qfrp-hm3j
Package: github.com/rancher/fleet (GO)
Severity: CRITICAL (CVSS 9.9)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 0.13.0, < 0.13.10
Patched in: 0.13.10

Summary: Fleet: Helm impersonation bypass of `RESTClientGetter` retains `cluster-admin` during template rendering

Details:
### Impact

Fleet's Helm deployer did not fully apply ServiceAccount impersonation in two code paths, allowing a tenant with git push access to a Fleet-monitored repository to read secrets from any namespace on every downstream cluster targeted by their `GitRepo`.

**Helm `lookup` bypass:** The Helm template engine ran Kubernetes API queries with the fleet-agent's cluster-admin credentials instead of the impersonated ServiceAccount. A chart template could therefore access resources beyond the tenant's RBAC scope.

**`valuesFrom` bypass:** Secret and ConfigMap references in `fleet.yaml` `helm.valuesFrom` were read using the fleet-agent's cluster-admin client. A tenant could reference resources in namespaces the impersonated ServiceAccount has no access to.
Both issues break Fleet's multi-tenant impersonation boundary. The leaked credentials may belong to external services, making the full impact non-deterministic.
Single-tenant deployments where all users are trusted are not affected.

**Important:**
- For the exposure of additional credentials, the final impact severity for confidentiality, integrity and availability is dependent on the permissions the leaked credentials have on their services.
- It is recommended to review for potentially leaked credentials in this scenario and to change them if deemed necessary.

Please consult the associated  [MITRE ATT&CK - Technique - Account Access Removal](https://attack.mitre.org/techniques/T1531/) for further information about this category of attack.

### Patches

Both issues are fixed by ensuring the Helm action configuration consistently uses the impersonated ServiceAccount credentials throughout all Helm operations.

Patched versions of Rancher include releases `v2.14.1`, `v2.13.5`, `v2.12.9`, and `v2.11.13`. For Rancher `v2.10.11`, users must manually update their Fleet deployment to version`v0.11.13`.

### Workarounds

No workaround fully mitigates the issue for multi-tenant deployments. The patches should be applied as soon as they are available.

The following measures reduce the attack surface but do not close either vulnerability:

- Restrict git push access to Fleet-monitored repositories to trusted users only. In a multi-tenant setup this removes the precondition entirely, but is often not operationally viable.
- Use `GitRepoRestriction` resources to limit which ServiceAccounts each namespace is allowed to use, restricting the set of users who can configure impersonation at all.
- Audit deployed chart templates for `lookup` calls and `fleet.yaml` files for cross-namespace `valuesFrom` references as a detective control.

### Resources

If there are any questions or comments about this advisory:

- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.
- Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
- Verify using the [support matrix](https://www.suse.com/suse-rancher/su