Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-09-28T15:17:24.927Z",
  "pubdate": "2026-09-28T15:17:24.927Z",
  "executiveSummary": "A cross-tenant authorization vulnerability exists in SUSE Rancher Fleet caused by improper validation of cluster labels during the agent-initiated registration process.\nThe vulnerability allows an attacker to manipulate cluster metadata, specifically within the reserved 'management.cattle.io/' namespace, during the registration of a new cluster.\nBy supplying malicious labels, an attacker can influence the targeting logic used by the Fleet controller to assign GitRepo and Bundle resources.\nThis permits a malicious actor to hijack deployments or configuration intended for other clusters within a shared Fleet workspace namespace, leading to unauthorized resource access and potential privilege escalation across tenant boundaries.\nThe issue affects multiple versions of SUSE Rancher Fleet, including 0.16 before 0.16.1, 0.15 before 0.15.6, 0.14 before 0.14.10, 0.13 before 0.13.15, and 0.12 before 0.12.19.\nExploitation requires the ability to register a cluster into a shared workspace namespace, presenting a significant security risk in multi-tenant environments where proper isolation is expected but not enforced.",
  "technicalDetails": "The vulnerability originates from a failure in the Fleet agent registration workflow to sanitize or restrict cluster labels provided by the registering client. During the Cluster object creation process, the Fleet controller improperly trusts labels supplied by the registering agent.\nCrucially, this lack of validation allows for the injection of labels belonging to the 'management.cattle.io/' namespace. These labels are typically reserved for internal cluster metadata, such as the cluster display name, which the system uses to track and categorize resources.\nThe attack flow begins when an attacker, authorized to register a cluster into a shared Fleet workspace, submits a crafted registration request containing arbitrary labels. By injecting specific labels that match the targeting selectors of existing GitRepo or Bundle resources, the attacker forces the Fleet controller to associate those resources with their own cluster.\nFleet relies on these label selectors to determine which clusters should receive specific application bundles or configuration sets. By successfully spoofing the cluster identity via label injection, the attacker intercepts deployments or sensitive configurations that were administratively scoped to different, legitimate clusters within the same workspace.\nThe scope of impact is the cross-tenant boundary; because the controller fails to verify the authenticity or origin of these metadata labels, it treats the attacker-controlled cluster as a legitimate destination for targeted workloads. This bypasses the logical isolation between tenants that rely on label-based selectors for workload distribution.\nThe affected components are the cluster registration and label processing modules within the Fleet controller. The vulnerability is present across numerous versions, specifically 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, and 0.12 before 0.12.19. Exploitation is facilitated by the standard agent-to-manager registration protocol, requiring only that the attacker has the necessary permissions to initiate cluster registration within a shared workspace namespace. Post-exploitation, the attacker gains the ability to execute unauthorized deployments, potentially leading to container breakout, data exfiltration, or lateral movement within the cluster orchestration layer."
}