An Improper Authorization vulnerability in SUSE Rancher, allows any user who has permissions to create/edit cluster role template bindings or project role template bindings (such as cluster-owner, manage cluster members, project-owner and manage project members) to gain owner permission in another project in the same cluster or in another project on a different downstream cluster. This issue affects: SUSE Rancher Rancher versions prior to 2.6.7; Rancher versions prior to 2.5.16.

Affected: Go: github.com/rancher/rancher

### Impact

An issue was discovered in Rancher versions up to and including 2.5.15 and 2.6.6 where a flaw with authorization logic allows privilege escalation through cluster role template binding (CRTB) and project role template binding (PRTB). This issue does not affect the local cluster, it affects only downstream clusters.

The vulnerability can be exploited by any user who has permissions to create/edit cluster role template bindings or project role template bindings (such as `cluster-owner`, `manage cluster members`, `project-owner` and `manage project members`) to gain `owner` permission in another project in the same cluster or in another project on a different downstream cluster.

- The user must have `kubectl` access in the local cluster to exploit this scenario.

- This can only be abused to gain `cluster-owner` permission on a different downstream cluster if the user is already `cluster-owner` on at least one downstream cluster.

- Example of a modified CRTB (note: the `clusterName` points to the cluster ID of the cluster that the privileges will be escalated and `namespace` points to the current cluster ID that the user has permissions): ``` kubectl edit clusterroletemplatebindings crtb-<crtb-ID> -n c-<cluster-ID> --- apiVersion: management.cattle.io/v3 clusterName: <ID-of-the-cluster-to-escalate> kind: ClusterRoleTemplateBinding metadata: annotations: <omitted> finalizers: - <omitted> generateName: crtb- labels: <omitted> cattl…