What is the CVSS score of CVE-2026-44935?

CVE-2026-44935 has a CVSS 3.1 base score of 9.9 (Critical). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. EPSS exploitation probability: 0.6%.

Which versions of Rancher Fleet are affected by CVE-2026-44935?

Rancher Fleet's multi-tenant architecture is vulnerable to a critical (CVSS 9.9) authorization bypass in which authenticated low-privileged tenants can access Secrets and ConfigMaps across all…. A patch is available.

How to fix or mitigate CVE-2026-44935?

Within 24 hours: Audit all Rancher Fleet production clusters for multi-tenant configurations; enumerate all low-privileged tenant accounts and service principals. Within 7 days: Implement RBAC policies restricting tenant access to assigned namespaces only; disable GitRepo and HelmOp CRD operations unless operationally critical; enable Kubernetes audit logging for ConfigMap and Secret access. Within 30 days: Monitor Rancher security advisories for patch availability; conduct forensic analysis of audit logs for indicators of cross-namespace data access; prepare and test patch deployment procedures.

Rancher Fleet CVE-2026-44935

EUVD-2026-41408 CRITICAL

Incorrect Authorization (CWE-863)

2026-07-01 https://github.com/rancher/fleet

GHSA-xr65-5cpm-g36x

Authentication Bypass Suse

9.9

CVSS 3.1 · Vendor: https://github.com/rancher/fleet

Severity by source

Vendor (https://github.com/rancher/fleet) PRIMARY

9.9 CRITICAL

AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

vuln.today AI

9.9 CRITICAL

Authenticated tenant (PR:L) reaches the API over the network with low complexity; broken tenant isolation crosses scope (S:C), yielding full cross-tenant C/I/A impact.

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

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:N

SUSE

CRITICAL

qualitative

Primary rating from Vendor (https://github.com/rancher/fleet).

CVSS VectorVendor: https://github.com/rancher/fleet

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Generated

Jul 01, 2026 - 21:16 vuln.today

CVE Published

Jul 01, 2026 - 20:45 github-advisory

CRITICAL 9.9

DescriptionCVE.org

Impact

A vulnerability in Fleet for Rancher Manager affects multi-tenancy environments where different tenants share the same downstream clusters (e.g., different privileged or untrusted teams inside the same organization).

On unpatched versions, tenants could bypass restrictions to access any config map or secret across all namespaces on the downstream cluster. They can create cluster-wide resources using HelmOp or Bundle without authorization. Specifically, an attacker can exploit this vulnerability in the following ways:

Use valuesFrom in fleet.yaml(through a GitRepo resource) or a `HelmOp resource to read the contents of any secret an on the downstream cluster, provided they know or can guess the name, namespace, and key.
Deploy HelmOp and Bundle resources without being restricted to a specific service account for the Fleet agent.

If you use Fleet in a multi-tenant environment, it's recommended that you:

Review your cluster and Fleet deployments logs for indicators of unauthorized access across tenant namespaces.
Rotate any service accounts and credentials that might have been exposed.

Please consult the associated MITRE ATT&CK - Technique - Unsecured Credentials for further information about this category of attack.

Patches

To resolve this vulnerability, upgrade to a patched version of Fleet. The new Policy resource allows you to:

Configure GitRepos, HelmOps, and Bundles to require a specific service account for the Fleet agent on downstream clusters used for deployment. The agent uses these designated service accounts for operations, blocking access to unauthorized resources.
Restrict HelmOp repository and chart URLs by using a regular expression. The regular expression is automatically anchored with ^ and $, meaning it must match the entire URL string.

Like GitRepoRestriction, a Policy resource must be created in the specific namespace you want to restrict, and it only applies to that namespace.

Note: Before applying a policy, ensure that the required service account is available on the downstream clusters and is configured with least-privilege permissions.

Patched versions of Fleet include releases v0.15.2, v0.14.6, 0.13.11, and v0.12.15.

Workarounds

If you can't upgrade to a fixed version, please make sure that tenants do not have shared access to the same downstream clusters.

Credits

This security issue was reported by the following collaborators according to our responsible disclosure policy:

Radisauskas Arnoldas from NATO and the NATO Cyber Security Centre (NCSC).

References

If you have any questions or comments about this advisory:

Reach out to the SUSE Rancher Security team for security related inquiries.
Open an issue in the Rancher repository.
Verify with our support matrix and product support lifecycle.

AnalysisAI

Cross-tenant authorization bypass in Rancher Fleet allows a low-privileged tenant in a multi-tenant environment to read any ConfigMap or Secret across all namespaces of a shared downstream cluster and to deploy cluster-wide resources without being bound to a restricted service account. The flaw (CWE-863, CVSS 9.9) is exploitable by authenticated tenants who abuse valuesFrom in fleet.yaml (via GitRepo) or HelmOp/Bundle resources; there is no public exploit identified at time of analysis and it is not listed in CISA KEV.

Technical ContextAI

Fleet is Rancher's GitOps continuous-delivery engine that reconciles GitRepo, HelmOp, and Bundle custom resources into deployments on downstream (managed) Kubernetes clusters via a per-cluster Fleet agent. The root cause is an incorrect-authorization / broken tenant-isolation defect (CWE-863): the Fleet agent performs operations without being constrained to a tenant-specific, least-privilege service account, so its broad permissions are inherited by any tenant able to submit a GitRepo/HelmOp/Bundle. The affected code is the Go module github.com/rancher/fleet (per the pkg:go CPE). Two concrete primitives are exposed - valuesFrom references in fleet.yaml or a HelmOp let a tenant pull the contents of arbitrary Secrets by name/namespace/key, and HelmOp/Bundle creation is not pinned to a designated agent service account, permitting creation of cluster-wide resources. The fix introduces a new Policy resource (namespace-scoped, like the existing GitRepoRestriction) that forces a specific service account for the agent and lets operators restrict HelmOp repository and chart URLs via an anchored regular expression.

RemediationAI

Upgrade Fleet to a patched release on your branch: Vendor-released patch v0.15.2, v0.14.6, v0.13.11, or v0.12.15 as documented in GHSA-xr65-5cpm-g36x. After upgrading, create a namespace-scoped Policy resource that pins GitRepos, HelmOps, and Bundles to a specific least-privilege Fleet agent service account, and use the Policy's anchored regex to constrain permitted HelmOp repository and chart URLs - but first ensure the designated service account already exists on each downstream cluster and is scoped to minimum permissions, or deployments will fail. If you cannot upgrade, the vendor workaround is to remove the exploitation precondition entirely by ensuring tenants do not share access to the same downstream clusters (dedicate clusters per tenant), accepting the trade-off of reduced cluster consolidation and higher operational cost. As post-incident hygiene, review cluster and Fleet logs for cross-tenant namespace access and rotate any service accounts and credentials that may have been exposed. For questions, contact the SUSE Rancher Security team (https://github.com/rancher/rancher/security/policy).