Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
7.1
Rancher allows containers to run as a privileged user
GHSA-hwm2-4ph6-w6m5
Summary
Rancher's default security settings for some users allow containers to run with elevated access. This increases the risk of a compromised container being used to attack the user's environment. To fix this, update to Rancher version 2.6.4 or later, or use a new security setting called `restricted-noroot` that prevents containers from running with elevated access.
What to do
- Update github.com rancher to version 2.6.4.
Affected software
| Vendor | Product | Affected versions | Fix available |
|---|---|---|---|
| github.com | rancher | > 2.0.0 , <= 2.6.4 | 2.6.4 |
Original title
Rancher's restricted PodSecurityPolicy does not prevent containers from running as a privileged user
Original description
### Impact
The `restricted` pod security policy (PSP), provided in Rancher versions from 2.0 up to and including 2.6.3, has a deviation from the [upstream](https://github.com/kubernetes/website/blob/6d22e08903d7dd44b049c4689fa882ae07f67de9/content/en/examples/policy/restricted-psp.yaml) `restricted` policy provided in Kubernetes, in which Rancher's PSP has `runAsUser` set to `runAsAny`, while upstream has `runAsUser` set to `MustRunAsNonRoot`. This allows containers to run as any user, including a privileged user (`root`), even when Rancher's `restricted` policy is enforced on a project or at cluster level.
A new `restricted-noroot` PSP was created to prevent pods from running as `root` when this policy is enforced. This new policy was introduced, instead of patching the current provided `restricted` policy, in order to avoid breaking users' workloads that are using the `restricted` PSP and that might be running as a privileged user.
**Note**: Running containers as `root` increases the risk of a compromised container being used by a malicious actor as an attack platform to further exploit the user's environment. It is a security best practice to avoid running containers as a privileged user and to limit its usage to workloads where it is strictly necessary.
### Patches
Patched versions include release 2.6.4 and later versions. The existing `restricted` PSP in Rancher 2.6.4 was not modified and still allows containers to run as a privileged user, as explained above. This fix was not backported to previous releases.
For Rancher 2.6.4 and later releases, users using the current `restricted` PSP and that want to prevent containers from running as `root`, are advised to migrate to the new `restricted-noroot` policy. Before doing this migration, it is necessary to verify if affected workloads are currently running as a privileged user and modify them accordingly to the users' own environment to run as a non-privileged user. A redeployment of the affected workload is necessary in order for the new PSP to take effect.
### Workarounds
For users running Rancher 2.6.3 and previous releases, which did not received this backport and that want to benefit from this fix, they can manually create a new `restricted-noroot` PSP on their clusters through Rancher UI. The template of the `restricted-noroot` policy provided in Rancher 2.6.4 is available in the [source code](https://github.com/rancher/rancher/blob/7410cef256c9ed22e8bf4609e5b2e9a1f63a0d05/pkg/data/management/podsecuritypolicytemplate_data.go#L101-L145). As a reminder, it is also necessary to manually verify and redeploy the running workload before enabling a more restricted pod security policy.
### References
For instructions on how to configure pod security policies using Rancher, please refer to the [documentation](https://rancher.com/docs/rancher/v2.6/en/admin-settings/pod-security-policies/) page. For more information on PSPs in Kubernetes, please refer to the Kubernetes [documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) ([permalink](https://github.com/kubernetes/website/blob/f5ec6b03db0925dc2b9cb9bbdc8135dcbeacbe0e/content/en/docs/concepts/policy/pod-security-policy.md)).
**Important reminder:** Pod security policies are considered deprecated since Kubernetes v1.21, and will be removed in Kubernetes v1.25. Consult Kubernetes' [documentation](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/) ([permalink](https://github.com/kubernetes/website/blob/f5ec6b03db0925dc2b9cb9bbdc8135dcbeacbe0e/content/en/docs/tasks/configure-pod-container/migrate-from-psp.md)) regarding how to migrate from PodSecurityPolicy to Kubernetes' built-in PodSecurity Admission Controller. For the list of supported Kubernetes versions in Rancher, please consult our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/).
### 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/).
The `restricted` pod security policy (PSP), provided in Rancher versions from 2.0 up to and including 2.6.3, has a deviation from the [upstream](https://github.com/kubernetes/website/blob/6d22e08903d7dd44b049c4689fa882ae07f67de9/content/en/examples/policy/restricted-psp.yaml) `restricted` policy provided in Kubernetes, in which Rancher's PSP has `runAsUser` set to `runAsAny`, while upstream has `runAsUser` set to `MustRunAsNonRoot`. This allows containers to run as any user, including a privileged user (`root`), even when Rancher's `restricted` policy is enforced on a project or at cluster level.
A new `restricted-noroot` PSP was created to prevent pods from running as `root` when this policy is enforced. This new policy was introduced, instead of patching the current provided `restricted` policy, in order to avoid breaking users' workloads that are using the `restricted` PSP and that might be running as a privileged user.
**Note**: Running containers as `root` increases the risk of a compromised container being used by a malicious actor as an attack platform to further exploit the user's environment. It is a security best practice to avoid running containers as a privileged user and to limit its usage to workloads where it is strictly necessary.
### Patches
Patched versions include release 2.6.4 and later versions. The existing `restricted` PSP in Rancher 2.6.4 was not modified and still allows containers to run as a privileged user, as explained above. This fix was not backported to previous releases.
For Rancher 2.6.4 and later releases, users using the current `restricted` PSP and that want to prevent containers from running as `root`, are advised to migrate to the new `restricted-noroot` policy. Before doing this migration, it is necessary to verify if affected workloads are currently running as a privileged user and modify them accordingly to the users' own environment to run as a non-privileged user. A redeployment of the affected workload is necessary in order for the new PSP to take effect.
### Workarounds
For users running Rancher 2.6.3 and previous releases, which did not received this backport and that want to benefit from this fix, they can manually create a new `restricted-noroot` PSP on their clusters through Rancher UI. The template of the `restricted-noroot` policy provided in Rancher 2.6.4 is available in the [source code](https://github.com/rancher/rancher/blob/7410cef256c9ed22e8bf4609e5b2e9a1f63a0d05/pkg/data/management/podsecuritypolicytemplate_data.go#L101-L145). As a reminder, it is also necessary to manually verify and redeploy the running workload before enabling a more restricted pod security policy.
### References
For instructions on how to configure pod security policies using Rancher, please refer to the [documentation](https://rancher.com/docs/rancher/v2.6/en/admin-settings/pod-security-policies/) page. For more information on PSPs in Kubernetes, please refer to the Kubernetes [documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) ([permalink](https://github.com/kubernetes/website/blob/f5ec6b03db0925dc2b9cb9bbdc8135dcbeacbe0e/content/en/docs/concepts/policy/pod-security-policy.md)).
**Important reminder:** Pod security policies are considered deprecated since Kubernetes v1.21, and will be removed in Kubernetes v1.25. Consult Kubernetes' [documentation](https://kubernetes.io/docs/tasks/configure-pod-container/migrate-from-psp/) ([permalink](https://github.com/kubernetes/website/blob/f5ec6b03db0925dc2b9cb9bbdc8135dcbeacbe0e/content/en/docs/tasks/configure-pod-container/migrate-from-psp.md)) regarding how to migrate from PodSecurityPolicy to Kubernetes' built-in PodSecurity Admission Controller. For the list of supported Kubernetes versions in Rancher, please consult our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/).
### 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 CVSS4.0
7.1
Vulnerability type
CWE-862
Missing Authorization
Published: 3 Mar 2026 · Updated: 7 Mar 2026 · First seen: 6 Mar 2026