Unrated

Privilege Escalation in Rancher via Cross-Cluster Project Name Collision

IdentifiersCVE-2024-22031CWE-269

CVE-2024-22031 is a privilege escalation vulnerability in Rancher caused by improper handling of project identity across clusters when projects share the same object name. According to the provided advisory, a user with permission to create projects on one cluster can create a project using the same name as an existing project in another cluster and thereby gain access to the other project. The issue appears to stem from namespace or object-name collision behavior across clusters, allowing authorization boundaries between clusters to be bypassed when duplicate project names exist.

For your environment

Are you exposed to this one?

Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.

Start free trial

ANALYST BRIEF

Impact, mitigation & remediation

What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.

Impact

What an attacker gets, and what they’ve been doing with it.

Successful exploitation allows a user who is authorized to create projects in one cluster to obtain unauthorized access to arbitrary projects in other clusters if they can create a same-named project. This results in privilege escalation across cluster boundaries and exposure of resources associated with the targeted project. Depending on the victim project contents and delegated permissions, this could enable unauthorized visibility or interaction with project-scoped resources.

Mitigation

If you can’t patch tonight, do this now.

If immediate patching is not possible, restrict or prevent users from creating projects whose object names duplicate project names used in other clusters. Administrators can identify potentially affected projects by running kubectl get projects -A -o=custom-columns='NAME:metadata.name' | sort | uniq -c on the local cluster and reviewing names that appear more than once across clusters. Any affected duplicate-name projects should be deleted and re-created to avoid namespace collisions.

Remediation

Patch, then assume compromise.

Upgrade Rancher to a fixed release: v2.11.1, v2.10.5, or v2.9.9. The v2.8 release line does not contain a fix, so deployments on v2.8 should upgrade to a newer supported version. After upgrading, if duplicate project names already exist across clusters, delete and re-create the affected projects to eliminate the collision condition.

PUBLIC EXPLOITS

Exploits

No public exploits tracked yet. Mallory keeps watching.

VALID 0 / 0 TOTALView more in app

No public exploit code observed for this vulnerability.

EXPOSURE SURFACE

Affected products & vendors

Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.

VendorProductType

Rancher LabsRancherapplication

Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.

ACTIVITY FEED

Recent activity

No public activity tracked yet. Mallory keeps watching.

0 SOURCESView more in app

No public activity observed for this vulnerability.

What this page doesn’t show

The version that knows your environment.

This page is what’s public. Mallory adds the parts that aren’t: which of your assets are affected, which adversaries are exploiting it right now, which detections to deploy, and what to do tonight.

Start free trial

Exposure mapping

Query your assets running an affected version, and investigate the blast radius.

Threat actor evidence

Every observed campaign linking this CVE to a named adversary.

Associated malware

Malware families riding this exploit, with evidence and IOCs.

Detection signatures

YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.

Vendor-by-vendor mapping

Cross-references every affected SKU, including bundled OEM variants.

Social activity