CVE-2024-22031

Executive Summary

CVE-2024-22031 is a privilege-escalation flaw in Rancher caused by improper authorization scoping (CWE-863). A user who is permitted to create a project on one cluster can name that project identically to an existing project in a different cluster, and because Rancher internally uses the project name as the namespace for storing related resources (PRTBs and secrets), the collision grants the user access to the other cluster's project. The vulnerability carries a CVSS 3.1 base score of 8.5 (High), targeting multi-cluster Rancher deployments with project-level self-service permissions.

Technical Analysis

The root cause is a name-collision / scope-confusion defect in Rancher's project resource model. According to the NVD description, Rancher stores resources related to a project inside a namespace "used on the local cluster to store related resources (PRTBs and secrets)," and that namespace "is the name of the project." This design ties the identity of the backing storage namespace to a user-controlled string (the project name) rather than to a globally unique identifier (such as the owning cluster plus a project UUID).

When a low-privileged user who can create projects on cluster A creates a project whose name matches an existing project on cluster B, the namespace that Rancher provisions or references collides with the namespace backing the other project. Authorization checks that are keyed on the project namespace — instead of on the (cluster, project) tuple — then evaluate against the wrong scope. The result is a horizontal reach across cluster boundaries that converts into vertical privilege escalation: the attacker gains access to the other project's resources, including its secrets and Project Role Template Bindings (PRTBs), which in turn can expose credentials and expand role assignments.

The weakness class is CWE-863, Incorrect Authorization. The core failure is the absence of a tenant/cluster qualifier in the resource key, allowing entity-name collision across isolated administrative domains. PRTBs and secrets are highly sensitive objects: PRTBs define the role bindings that grant permissions within a project, and secrets commonly hold service-account tokens, registry credentials, and application secrets. Read or write access to them is effectively equivalent to control over the target project's workloads.

Attack surface: the Rancher management API / UI project-creation workflow. The actor only needs project-creation rights on any cluster they can already reach — a modest precondition (PR:L, privilege required), which is why the vector is derived from a legitimate low-privileged account rather than an unauthenticated entry point. Exploitation complexity is rated High (AC:H) because it depends on prior knowledge of a matching project name and on the collision conditions in the target deployment; no user interaction is required (UI:N). Because a compromised project can cross into a separate cluster, the scope is Changed (S:C), and the confidentiality, integrity, and availability impacts are all High (C:H/I:H/A:H).

No code-level details (function names, API endpoints, file paths) are present in the provided data, and none are asserted here.

Exploitation Scenarios

The following chain is inferred from the vulnerability class and the NVD description; no public proof-of-concept exists, and no PoC or Nuclei template is available.

1. Reconnaissance / target identification. The attacker holds, or has obtained, a valid Rancher account with permission to create a project on at least one cluster. The attacker identifies a target project name that exists on a different cluster — for example through naming conventions, publicly documented project names, or observed resource references. Enumeration of project names is the key reconnaissance step, because a successful collision requires the attacker's chosen name to match the target.

2. Triggering the flaw class. Using the Rancher project-creation workflow, the attacker creates a new project on their own cluster and sets its name to the same value as the existing project on the other cluster. Because the backing namespace is derived from the project name, Rancher's name-to-namespace mapping resolves to the namespace that holds the other project's PRTBs and secrets. Any authorization check that is keyed solely on that namespace (rather than on cluster + project identity) now resolves to the victim project's scope.

3. Access acquisition. With the scope confusion in place, the attacker's project context is aliased onto the victim project's storage. The attacker can then reach the PRTBs and secrets associated with the target project. This is an authorization-logic attack — no injection, memory corruption, or remote code execution primitive is required; the payload is simply a project-creation request carrying the colliding name.

4. Post-exploitation impact. Access to the victim project's secrets yields credentials (registry logins, service-account tokens, application secrets), and access to PRTBs allows the attacker to influence or read role assignments. From there, the attacker can move laterally within the victim project's workloads and potentially escalate further within the second cluster. The attack is stealthy: it abuses normal, legitimate-looking project-creation operations and does not rely on exploits that signature-based tooling would typically flag.

Impact Assessment

Successful exploitation results in cross-cluster privilege escalation: a user with only project-creation rights gains unauthorized access to another tenant's project on a different cluster. Impact components, per the CVSS 3.1 vector, are all High — Confidentiality, Integrity, and Availability — with Scope Changed, reflecting that the compromise escapes the attacker's original security authority (their cluster) and impacts resources governed by a separate cluster. The attack requires network access (AV:N), non-trivial preconditions (AC:H), and low privileges (PR:L), with no user interaction (UI:N). The base score is 8.5 (High).

Blast radius is governed by what the victim project contains. Because PRTBs (role bindings) and secrets are exposed, the compromise can cascade from data disclosure into full control of the affected project's workloads. In organizations running Rancher as a central multi-cluster management plane, one colliding name can bridge isolation boundaries that the platform is expected to enforce — a serious multi-tenancy failure. The EPSS score is not yet available from FIRST.org, and CVE-2024-22031 is not listed in CISA KEV, so there is no confirmed evidence of exploitation in the wild; however, the low barrier (a valid low-privileged account) makes this attractive to insider threats and to attackers who have already obtained any tenant foothold.

Detection Guidance

Sigma Rule

title: Rancher Cross-Cluster Project Name Collision Privilege Escalation (CVE-2024-22031)
id: 3f6a9c1e-rancher-prj-collision
status: experimental
description: Detects creation of a Rancher project whose name matches an existing project on another cluster, consistent with CVE-2024-22031 scope confusion.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2024-22031
author: valtersit.com
logsource:
  product: rancher
  service: audit
detection:
  selection_action:
    verb: create
    objectRef.resource: projects
  selection_dup:
    - requestObject.metadata.name: '*'
  timeframe: 10m
  condition: selection_action | count(name) by requestObject.metadata.name > 1
falsepositives:
  - Legitimate use of identical project names across intentionally separate clusters
level: high
tags:
  - attack.t1078
  - cve.2024.22031

YARA Rule

rule CVE_2024_22031_Rancher_Project_Collision
{
    meta:
        description = "Detects Rancher project-creation references potentially tied to CVE-2024-22031 name-collision privilege escalation"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-22031"
        date = "2024-01-01"
    strings:
        $s1 = "projects" nocase
        $s2 = "projectRoleTemplateBinding" nocase
        $s3 = "PRTB" nocase
        $s4 = "namespace" nocase
    condition:
        (uint16(0) == 0x7B7D or true) and
        2 of ($s*) and filesize < 5MB
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2024-22031 Rancher cross-cluster project name collision attempt"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"/v3/projects"; nocase; http.request_body; content:"\"name\""; nocase; reference:cve,2024-22031; classtype:attempted-admin; sid:202422031; rev:1;)

Elastic Detection

sequence by user.name with maxspan=5m
  [ any where event.action == "create" and rancher.resource == "projects" ]
  [ any where event.action == "create" and rancher.resource == "projects" and
      rancher.project.name == "duplicate-detected" ]

Splunk SPL Query

index=rancher sourcetype=rancher:audit verb=create objectRef.resource=projects
| stats count values(cluster) as clusters values(user.username) as users by project_name
| where mvcount(clusters) > 1
| table _time project_name users clusters count

Wazuh OSSEC Rule

<group name="rancher,cve-2024-22031,">
  <rule id="100131" level="12">
    <decoded_as>json</decoded_as>
    <field name="verb">create</field>
    <field name="objectRef.resource">projects</field>
    <description>CVE-2024-22031: Rancher project creation activity - possible cross-cluster project name collision privilege escalation</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>privilege_escalation,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 2/4 (CLAIMED — a single source, GHSA, claims a patch exists; this is not independently confirmed, and no specific fixed version is published in the data provided).

1. Immediate mitigations:

   • Restrict project-creation permissions. Where feasible, remove or tightly constrain the ability of untrusted/self-service users to create projects, since project-creation rights are the sole precondition for this attack.
   • Enforce unique, cluster-qualified project naming: do not allow identical project names across clusters that share a management plane, and audit existing names for collisions.
   • Review and rotate secrets and PRTBs in any project whose name is duplicated on another cluster.
   • Apply least privilege to PRTBs so that a single namespace exposure does not translate into broad workload control.

2. Patch/upgrade steps:

   • Monitor the Rancher GitHub Security Advisory (GHSA) referenced in the patch sources for the official fixed release. Because patch confidence is only CLAIMED, verify the advisory directly with the vendor before relying on it.
   • Track the Rancher release notes for the version that changes the namespace-derivation logic so that resource identity is keyed on cluster + project rather than project name alone.
   • Until a confirmed fix is deployed, treat project-name collisions as an active risk and remediate by renaming or removing conflicting projects.

3. Long-term hardening:

   • Enforce globally unique identifiers as the authoritative key for authorization decisions; never key an authorization or namespace boundary on a user-supplied display name (CWE-863 root cause).
   • Adopt multi-tenancy isolation reviews and automated drift detection across clusters to catch name collisions early.
   • Audit cluster/tenant boundary enforcement periodically and validate that cross-cluster access controls behave as documented.

References

• NVD — CVE-2024-22031: https://nvd.nist.gov/vuln/detail/CVE-2024-22031
• Rancher GitHub Security Advisory (GHSA) — cited as the sole patch source; consult the Rancher GHSA repository for the confirmed advisory: https://github.com/rancher/rancher/security/advisories
• MITRE CWE-863 — Incorrect Authorization: https://cwe.mitre.org/data/definitions/863.html
• FIRST EPSS — CVE-2024-22031 (score not yet published at time of writing): https://api.first.org/data/v1/epss?cve=CVE-2024-22031
• CISA Known Exploited Vulnerabilities Catalog (CVE-2024-22031 not listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog

No known threat actor campaigns or exploit-in-the-wild evidence are associated with CVE-2024-22031 in the provided data.