CVE-2026-104615

The SUSE Rancher Fleet controller did not sufficiently restrict which kubeconfig secrets a Fleet Cluster object was allowed to reference. As a result, an ordinary user could define a cluster in a namespace they control and associate it with administrative credentials for the management cluster, causing the controller to manage the management cluster on that user's behalf with elevated privileges. This affects Fleet 0.16.0–0.16.3, 0.15.0–0.15.8, 0.14.0–0.14.12, 0.13.0–0.13.17 and possibly older versions.

Missing validation of 'valuesFrom' references in Helm Deployer of SUSE Rancher Fleet allows owners of one tenant to access fleet credentials of other tenants. Affected versions: 0.15 before 0.15.2, 0.14 before 0.14.6, 0.13 before 0.13.11, and 0.12 before 0.12.15.

In Rancher Manager, a vulnerability was identified where the Fleet agent wrote resources to downstream clusters using its own cluster-admin credentials instead of the ServiceAccount pinned to the deployment. It affects multi-tenancy environments where different tenants share the same downstream clusters, potentially leading to overwritten configuration files. This issue affected SUSE Rancher Fleet 0.16 before 0.16.2, 0.15 before 0.15.7, and 0.14 before 0.14.11.

A privilege mismatch was found in Fleet. When a bundle requested namespace labels or annotations through the namespaceLabels and namespaceAnnotations options, the resulting namespace metadata update was not subject to the same authorization as the rest of the bundle's deployment. As a result, a bundle could change labels and annotations on a target namespace even when the identity it was pinned to was not authorized to modify that namespace.

A vulnerability was discovered in Fleet's Git webhook receiver (the gitjob webhook service). When a webhook secret is not configured, incoming webhook requests are accepted without verification, and processing a request can change the spec.pollingInterval field of a matching GitRepo resource in any namespace. A caller with network access to the webhook service and no Kubernetes credentials can therefore alter GitRepo configuration outside the namespaces they are authorized for.

A cross-tenant authorization issue was discovered in SUSE Rancher Fleet. During agent-initiated cluster registration, cluster labels supplied by the registering agent, including labels in the reserved management.cattle.io/ namespace such as the cluster display name label, were applied to the resulting upstream Cluster object. Because Fleet resolves GitRepo and Bundle targets from those cluster labels, a party able to register a cluster into a Fleet workspace namespace shared with other tenants could cause its own cluster to satisfy targeting rules that administrators intended for a different cluster. This affects SUSE Rancher Fleet 0.16 before 0.16.1, 0.15 before 0.15.6, 0.14 before 0.14.10, 0.13 before 0.13.15, 0.12 before 0.12.19 and older versions.

A user who can supply bundle content to a repository referenced by a GitRepo resource, for example through Git push access or permission to create/modify a GitRepo, can cause SUSE Rancher Fleet to read files from the filesystem of the environment processing the bundle and include their contents in the generated Bundle resource. This can expose configuration or credential material the user has no Kubernetes RBAC permission to read, including Helm registry credentials made available to the bundle-processing job when per-path Helm credentials are configured.

A vulnerability in SUSE Rancher Fleet allows forgery of unauthenticated webhook requests, which can be exploited by a remote attacker to cause a denial of service (DoS) or a downgrade attack on other repositories in the system. The issue affects versions 0.15 before 0.15.2, 0.14 before 0.14.6, 0.13 before 0.13.11, and 0.12 before 0.12.5.

In SUSE Rancher Fleet versions 0.15 before 0.15.2, 0.14 before 0.14.6, 0.13 before 0.13.11, and 0.12 before 0.12.15, missing filtering in the bundle reader when the helmRepoURLRegex field is not set on a GitRepo resource causes Helm authentication credentials (BasicAuth) to be forwarded to any URL specified in the helm.repo field of a fleet.yaml file. This allows attackers with push access to Fleet-monitored git repositories to leak Helm access credentials.