Rancher privilege escalation flaw grants cross-cluster access to project creators
A high-severity flaw in SUSE Rancher allows users to escalate privileges by creating duplicate project names across clusters. Affected versions are listed.
Key points
- CVE-2024-22031 has a CVSS score of 8.5, classified as high severity.
- The flaw affects SUSE Rancher versions prior to 2.9.9, 2.10.5, and 2.11.1.
- Attackers can access resources in other clusters by exploiting namespace naming logic.
A vulnerability in SUSE Rancher allows authenticated users to escalate privileges and access resources in clusters where they do not belong. The flaw, tracked as CVE-2024-22031, carries a CVSS score of 8.5, which is rated as high severity. It stems from how the platform manages project namespaces. Versions 2.9.9, 2.10.5, and 2.11.1 are the boundaries for affected releases.
How it unfolded
- The flaw arises because Rancher uses the project name to create namespaces on the local cluster.
- These namespaces store related resources, including Project Role Template Bindings and secrets.
- A user with permission to create a project in one cluster can exploit this naming convention.
- By creating a project with the same name as an existing project in a different cluster, the user gains access to that other project.
Who is affected
SUSE Rancher deployments running versions before 2.9.9, before 2.10.5, or before 2.11.1 are vulnerable. According to the National Vulnerability Database record, the issue is tied to CWE-863, which relates to incorrect access control. Any environment where users have the ability to create projects is at risk. The impact is lateral movement between clusters via shared project names.
Our take on the response
The vulnerability exploits a fundamental assumption in namespace isolation. By tying resource storage directly to project names, the system fails to account for name collisions across different cluster contexts. This design choice creates a direct path for privilege escalation. It highlights the need for strict uniqueness checks or isolated namespace generation strategies in multi-cluster management platforms.
Who needs to act first
Teams should prioritize auditing environments where users have project creation rights. Check whether any projects share names across different clusters. If duplicates exist, isolate those namespaces immediately to prevent unauthorized access. Restrict project creation permissions to trusted administrators only. Monitor audit logs for new project creations. Prepare to apply updates as soon as the vendor releases them. Do not assume local clusters are isolated from remote naming conflicts.
What to do and how to stay safe: SUSE Rancher
- Identify all clusters running Rancher versions prior to 2.9.9, 2.10.5, or 2.11.1.
- Audit project names across all managed clusters to detect any duplicates.
- Restrict the ability to create new projects to a limited set of trusted administrators.
- Monitor access logs for unusual activity in projects that share names with other clusters.
Step-by-step guide: Vulnerability Prioritization: How to Rank Risks Without Wasting Time
General security guidance from the Patch Observer newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
What is the CVSS score for CVE-2024-22031?
The CVSS score is 8.5, which is classified as high severity.
Which Rancher versions are affected by this vulnerability?
Versions before 2.9.9, before 2.10.5, and before 2.11.1 are affected.
How does the privilege escalation occur?
Users create a project with the same name as one in another cluster, gaining access to the other project's resources.
