Rancher Project Name Collision Enables Cross-Cluster Privilege Escalation

A privilege escalation flaw in SUSE Rancher allows users to bypass cluster isolation by creating projects with duplicate names. According to the National Vulnerability Database, this issue affects specific versions of the platform and results in unauthorized access to resources in other clusters. The vulnerability stems from how the system handles project namespaces.

Root cause

The National Vulnerability Database identifies the weakness as CWE-863, improper restriction of operations within a namespace. The issue occurs because the local cluster uses the project name to store related resources, including Project Role Template Bindings and secrets. This naming convention creates a collision risk when projects share identical names across different clusters.

Attack path

A user with the ability to create a project on a specific cluster can exploit this flaw. By creating a new project that matches the name of an existing project in a different cluster, the user gains access to that remote project. This action results in privilege escalation, allowing the attacker to interact with resources they should not control.

Affected versions

The National Vulnerability Database lists the following versions as affected by CVE-2024-22031:

• SUSE Rancher versions prior to 2.9.9
• SUSE Rancher versions prior to 2.10.5
• SUSE Rancher versions prior to 2.11.1

Mitigation

• Upgrade SUSE Rancher to version 2.9.9 or later, 2.10.5 or later, or 2.11.1 or later.
• Audit existing project names across all clusters to identify and resolve duplicate naming conflicts.
• Review project creation permissions to ensure only trusted users can establish new projects.
• Monitor for unusual access patterns involving cross-cluster resource interactions.

Signals worth monitoring

Teams usually check audit logs for project creation events that match existing names in other clusters. Security operations centers should alert on users accessing projects outside their assigned scope. Reviewing role template bindings can reveal unexpected permission grants. Checking for duplicate project names across the environment helps identify potential exploitation. Monitoring for unauthorized secret access provides early warning. Analyzing user activity patterns for anomalies in project management functions supports detection.

What to do and how to stay safe: Rancher

• Verify your Rancher version against the affected list and apply updates if necessary.
• Inventory all project names across your clusters to ensure uniqueness.
• Restrict project creation rights to minimize the attack surface.
• Monitor logs for unusual access patterns involving cross-cluster resources.

Step-by-step guide: Attack Surface Management: 6 Common Misreadings and Correct Views

General security guidance from the NetSec 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 National Vulnerability Database rates the vulnerability as high with a CVSS score of 8.5.

Which Rancher versions are not affected?

Versions 2.9.9 and later, 2.10.5 and later, and 2.11.1 and later are not affected.

How does the vulnerability allow privilege escalation?

By creating a project with the same name as an existing project in a different cluster, users gain access to the other project.