Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
9.1
Rancher Privilege Escalation: Downstream Cluster Access
GHSA-6x34-89p7-95wg
CVE-2022-31247
Summary
Rancher users with permission to edit cluster or project role templates in a cluster can gain elevated access to other projects or downstream clusters. This can happen if they have `kubectl` access in the local cluster. To fix, update to at least Rancher 2.5.16 or 2.6.7.
What to do
- Update github.com rancher to version 2.5.16.
- Update github.com rancher to version 2.6.7.
Affected software
| Vendor | Product | Affected versions | Fix available |
|---|---|---|---|
| github.com | rancher | > 2.5.0 , <= 2.5.15 | 2.5.16 |
| github.com | rancher | > 2.6.0 , <= 2.6.6 | 2.6.7 |
| suse | rancher | > 2.5.0 , <= 2.5.16 | – |
| suse | rancher | > 2.6.0 , <= 2.6.7 | – |
Original title
Rancher has downstream cluster privilege escalation through cluster and project role template binding (CRTB/PRTB)
Original description
### 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>
cattle.io/creator: norman
name: crtb-<crtb-ID>
namespace: c-<current-cluster-ID>
roleTemplateName: cluster-owner
userName: u-<user-ID>
userPrincipalName: local://u-<user-ID>
```
An artifact to flag the exploitation of this issue is that the `namespace` of the CRTB/PRTB will not match the cluster name (`clusterName`) of the CRTB/PRTB. For example, every CRTB in the `c-123xyz` namespace should have a cluster name of `c-123xyz`. If instead, the cluster name is `c-abc567`, for example, this is likely a result of a user exploiting this flaw.
For more information about cluster and project roles, please consult Rancher's [documentation](https://rancher.com/docs/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/).
### Patches
Patched versions include releases 2.5.16, 2.6.7 and later versions.
### Workarounds
Limit access in Rancher to trusted users. There is not a direct mitigation besides upgrading to the patched Rancher versions.
**Important:**
- It is highly advised to check the local and downstream clusters for potential unrecognized CRTBs (`kubectl get clusterroletemplatebindings -A`) and PRTBs (`kubectl get projectroletemplatebindings -A`) assignments.
- The ability to add other users to projects and clusters is a highly-privileged permission which may result in users being able to operate beyond their explicitly specified RBAC. It is recommended that this permission be granted selectively.
The following script can be used as a helper to detect possible deviations of CRTBs and PRTBs that do not match the expected value. Further investigation is required to determine if the flagged objects were maliciously modified or not. The script requires `kubectl` access to the `local` cluster and the `jq` command.
```shell
#!/usr/bin/env bash
echo "CRTBs that don't match cluster:"
kubectl get clusterroletemplatebindings -A -o=jsonpath="{range .items[?(@[email protected])]}{.metadata.name}{'\n'}{end}"
echo "PRTBs that don't match project:"
kubectl get projectroletemplatebindings -A -ojson | jq -r '.items[]|.metadata as $m|select(.projectName|endswith($m.namespace)|not)|.metadata.name'
```
### For more information
If you have any questions or comments about this advisory:
* Reach out to [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.
* Open an issue in [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
* Verify our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).
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>
cattle.io/creator: norman
name: crtb-<crtb-ID>
namespace: c-<current-cluster-ID>
roleTemplateName: cluster-owner
userName: u-<user-ID>
userPrincipalName: local://u-<user-ID>
```
An artifact to flag the exploitation of this issue is that the `namespace` of the CRTB/PRTB will not match the cluster name (`clusterName`) of the CRTB/PRTB. For example, every CRTB in the `c-123xyz` namespace should have a cluster name of `c-123xyz`. If instead, the cluster name is `c-abc567`, for example, this is likely a result of a user exploiting this flaw.
For more information about cluster and project roles, please consult Rancher's [documentation](https://rancher.com/docs/rancher/v2.6/en/admin-settings/rbac/cluster-project-roles/).
### Patches
Patched versions include releases 2.5.16, 2.6.7 and later versions.
### Workarounds
Limit access in Rancher to trusted users. There is not a direct mitigation besides upgrading to the patched Rancher versions.
**Important:**
- It is highly advised to check the local and downstream clusters for potential unrecognized CRTBs (`kubectl get clusterroletemplatebindings -A`) and PRTBs (`kubectl get projectroletemplatebindings -A`) assignments.
- The ability to add other users to projects and clusters is a highly-privileged permission which may result in users being able to operate beyond their explicitly specified RBAC. It is recommended that this permission be granted selectively.
The following script can be used as a helper to detect possible deviations of CRTBs and PRTBs that do not match the expected value. Further investigation is required to determine if the flagged objects were maliciously modified or not. The script requires `kubectl` access to the `local` cluster and the `jq` command.
```shell
#!/usr/bin/env bash
echo "CRTBs that don't match cluster:"
kubectl get clusterroletemplatebindings -A -o=jsonpath="{range .items[?(@[email protected])]}{.metadata.name}{'\n'}{end}"
echo "PRTBs that don't match project:"
kubectl get projectroletemplatebindings -A -ojson | jq -r '.items[]|.metadata as $m|select(.projectName|endswith($m.namespace)|not)|.metadata.name'
```
### For more information
If you have any questions or comments about this advisory:
* Reach out to [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries.
* Open an issue in [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository.
* Verify our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).
ghsa CVSS3.1
9.1
Vulnerability type
CWE-285
Improper Authorization
CWE-863
Incorrect Authorization
Published: 3 Mar 2026 · Updated: 7 Mar 2026 · First seen: 6 Mar 2026