Description

A vulnerability has been identified within Rancher Manager 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, for example different privileged or untrusted teams inside the same organization. This could lead 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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-28T16:17:16.150Z",
  "pubdate": "2026-09-28T16:17:16.150Z",
  "executiveSummary": "A privilege escalation and improper authorization vulnerability exists in SUSE Rancher Fleet where the Fleet agent incorrectly utilizes cluster-admin credentials rather than the restricted ServiceAccount associated with a deployment.\nThis flaw specifically impacts multi-tenant environments where shared downstream clusters host multiple tenants with varying trust levels.\nThe vulnerability allows a tenant to exert unauthorized control over cluster resources, potentially overwriting configuration files or modifying sensitive objects that should be restricted based on the tenant's assigned ServiceAccount permissions.\nBy bypassing the intended least-privilege security boundaries, a malicious actor or a compromised tenant can escalate their operational scope to that of a cluster-admin within the downstream cluster, undermining the isolation guarantees provided by the Rancher Fleet multi-tenancy model.\nExploitation requires the attacker to have legitimate access to initiate deployments or manage resources within the Fleet framework, leveraging the agent's misconfiguration to perform operations outside the scope of their assigned identity.\nThe risk is critical in organizations relying on Fleet for cross-team resource management on shared infrastructure.",
  "technicalDetails": "The root cause of this vulnerability lies in an improper credential selection logic within the Fleet agent component of Rancher Manager. When the Fleet agent synchronizes resources to downstream Kubernetes clusters, it fails to enforce the identity isolation policy that dictates the use of a ServiceAccount pinned specifically to the individual deployment manifest.\nInstead of delegating the operation to the scoped ServiceAccount, the agent incorrectly falls back to its own internal execution identity. In many Rancher deployment scenarios, the Fleet agent operates with cluster-admin privileges to ensure it can successfully reconcile complex cluster states. Consequently, any resource modification or configuration write initiated by the agent inherits these elevated permissions rather than the constrained RBAC profile defined for the tenant-specific deployment.\nThe attack flow proceeds as follows: First, a tenant with access to the Fleet management interface constructs a malicious or misconfigured deployment manifest targeting a downstream cluster. Due to the failure in the agent's permission handling, the agent processes this request using its elevated cluster-admin credentials. When the agent writes the configuration to the downstream cluster, the Kubernetes API server treats the operation as an authenticated request from the agent's high-privilege context rather than the restricted user context. This bypasses the intended RBAC controls, allowing the tenant to overwrite existing configuration files, modify ClusterRoles, or inject unauthorized resources into namespaces they would otherwise be prohibited from accessing.\nThis flaw is persistent across SUSE Rancher Fleet 0.16 before 0.16.2, 0.15 before 0.15.7, and 0.14 before 0.14.11. The vulnerability is triggered during standard agent reconciliation loops. Because the agent's own credentials are utilized globally for resource writes, the impact is effectively a complete loss of multi-tenant isolation on the affected downstream cluster. An attacker can achieve unauthorized persistence or perform destructive actions by overwriting critical system configurations. Successful exploitation does not require external network exposure beyond the reach of the Fleet management plane, as the logic failure is internal to the agent's reconciliation process. The result is a total subversion of the intended security policy regarding resource ownership and privilege separation within the shared cluster architecture."
}