In Rancher 2.x before 2.6.13 and 2.7.x before 2.7.4, an incorrectly applied authorization check allows users who have certain access to a namespace to move that namespace to a different project.

Affected: Go: github.com/rancher/rancher

### Impact A vulnerability was identified in which users with update privileges on a namespace, can move that namespace into a project they don't have access to. After the namespace transfer is completed, their previous permissions are still preserved, which enables them to gain access to project-specific resources (such as [project secrets](https://ranchermanager.docs.rancher.com/how-to-guides/new-user-guides/kubernetes-resources-setup/secrets#creating-secrets-in-projects)). In addition, resources in the namespace will now count toward the [quota limit](https://ranchermanager.docs.rancher.com/how-to-guides/advanced-user-guides/manage-projects/manage-project-resource-quotas/about-project-resource-quotas) of the new project, potentially causing availability issues.

User with roles `Project Owner` and `Project Member` on the source project can exploit this vulnerability; however, this would also apply to custom roles with similar privileges.

The patched version include an improved RBAC mechanism, which checks if the user has the correct permissions before the namespace move takes place.

### Patches Patched versions include releases `2.6.13`, `2.7.4` and later versions.

### Workarounds There is no direct mitigation besides updating Rancher to a patched version.

### For more information If you have any questions or comments about this advisory:

- Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquirie…

Ein entfernter, authentisierter Angreifer kann mehrere Schwachstellen in Rancher ausnutzen, um seine Privilegien zu erhöhen, Sicherheitsvorkehrungen zu umgehen oder einen Cross Site Scripting angriff durchzuführen.