Vulnerabilities affecting this package (0)
| Vulnerability |
Summary |
Fixed by |
|
This package is not known to be affected by vulnerabilities.
|
Vulnerabilities fixed by this package (1)
| Vulnerability |
Summary |
Aliases |
|
VCID-jjbj-zndz-33dm
|
Fleet: Helm impersonation bypass of `RESTClientGetter` retains `cluster-admin` during template rendering
### 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/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).
|
CVE-2026-41050
GHSA-765j-qfrp-hm3j
|