Rancher users who can create Projects can gain access to arbitrary projects

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

A vulnerability has been identified within Rancher where a user with the ability to create a project, on a certain cluster, can create a project with the same name as an existing project in a different cluster. This results in the user gaining access to the other project in the different cluster, resulting in a privilege escalation. This happens because the namespace used on the local cluster to store related resources (PRTBs and secrets) is the name of the project.

Source published

15 Oct 2026 08:21:02 UTC

Source modified

16 Oct 2026 03:56:35 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 8.5 CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

A vulnerability has been identified within Rancher where a user with the ability to create a project, on a certain cluster, can create a project with the same name as an existing project in a different cluster. This results in the user gaining access to the other project in the different cluster, resulting in a privilege escalation. This happens because the namespace used on the local cluster to store related resources (PRTBs and secrets) is the name of the project.

Source published

Oct 15, 2026, 8:21:02 AM (timezone not stated)

Source modified

Oct 16, 2026, 3:56:35 AM (timezone not stated)

Observed here

31 Oct 2026 20:16:38 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 8.5 CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

A vulnerability has been identified within Rancher where a user with the ability to create a project, on a certain cluster, can create a project with the same name as an existing project in a different cluster. This results in the user gaining access to the other project in the different cluster, resulting in a privilege escalation. This happens because the namespace used on the local cluster to store related resources (PRTBs and secrets) is the name of the project.

Source published

15 Oct 2026 09:17:14 UTC

Source modified

27 Oct 2026 19:10:00 UTC

Observed here

29 Oct 2026 01:13:19 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 8.5 CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

### Impact A vulnerability has been identified within Rancher where a user with the ability to create a project, on a certain cluster, can create a project with the same name as an existing project in a different cluster. This results in the user gaining access to the other project in the different cluster, resulting in a privilege escalation. This happens because the namespace used on the local cluster to store related resources (PRTBs and secrets) is the name of the project. Please consult the associated [MITRE ATT&CK - Technique - Privilege Escalation](https://attack.mitre.org/tactics/TA0004/) for further information about this category of attack. ### Patches Patched versions include releases `v2.11.1`, `v2.10.5`, `v2.9.9`. The fix involves the following changes: **Rancher:** - Instead of using the project name as the namespace, Rancher will instead be using a new field on the project spec called backingNamespace. If that field exists, use that for the project namespace going forward. However, if the project does not have that field filled out (likely because it existed before this change), Rancher will continue using the name for the namespace. **Rancher Webhook:** - New mutation on create `project.Status.BackingNamespace` to be `SafeConcatName(project.Spec.ClusterName, project.Name)`; - Generate the name manually within the mutating webhook, because normally, name generation happens after the mutating webhooks; - Removed a validation where `projectName` and `Namespace` had to be the same for PRTBs, since PRTBs now go in `project.BackingNamespace`; - On update, if `BackingNamespace` isn't set, set it to `project.Name`. For existing objects after update this will help unify them to the new projects. - The `BackingNamespace` can't be edited after it's set. **Note: Rancher v2.8 release line does not have the fix for this CVE. The fix for v2.8 was considered too complex and with the risk of introducing instabilities right before this version goes into end-of-life (EOL), as documented in [SUSE’s Product Support Lifecycle](https://www.suse.com/lifecycle/#suse-rancher-prime) page. Please see the section below for workarounds or consider upgrading to a newer and patched version of Rancher.** ### Workarounds If you can't upgrade to a fixed version, please make sure that: - Users are not allowed to create projects with the same object names from another cluster. To identify if this security issue could have been abused within your system, you need to find if there are any projects with the same name but on different clusters. To do that, run the following command in the local cluster as an administrator: ``` kubectl get projects -A -o=custom-columns='NAME:metadata.name' | sort | uniq -c ``` That command will list all project names, and show the instances of each name. Any project with more than 1 instance is affected by this security issue. To remedy the situation, the projects will need to be deleted and re-created to ensure no namespace collisions happen. While it would be possible to delete all but 1 of the projects with the same name, this is unadvisable because a user could have given themselves access to the wrong project. ### References If you have any questions or comments about this advisory: - Reach out to the [SUSE Rancher Security team](https://github.com/rancher/rancher/security/policy) for security related inquiries. - Open an issue in the [Rancher](https://github.com/rancher/rancher/issues/new/choose) repository. - Verify with our [support matrix](https://www.suse.com/suse-rancher/support-matrix/all-supported-versions/) and [product support lifecycle](https://www.suse.com/lifecycle/).

Source published

25 Apr 2025 15:09:26 UTC

Source modified

10 Sep 2026 03:50:23 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

Publisher rating · HIGH

Rancher users who can create Projects can gain access to arbitrary projects in github.com/rancher/rancher. NOTE: The source advisory for this report contains additional versions that could not be automatically mapped to standard Go module versions. (If this is causing false-positive reports from vulnerability scanners, please suggest an edit to the report.) The additional affected modules and versions are: github.com/rancher/rancher from v2.8.0 before v2.9.9, from v2.10.0 before v2.10.5, from v2.11.0 before v2.11.1.

Source published

5 May 2025 16:13:00 UTC

Source modified

2 Jul 2026 16:59:30 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.