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

CVE-2026-41050 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.0%.

Which versions of Fleet are affected by CVE-2026-41050?

CVE-2026-41050 is a critical authentication bypass in Rancher Fleet (versions 0.12.0-0.15.0) that allows tenant users with git push access to impersonate cluster-admin and extract secrets from any…. A patch is available.

How to fix or mitigate CVE-2026-41050?

Within 24 hours: inventory all Rancher Fleet deployments and identify affected versions (0.12.0-0.15.0); notify teams managing multi-tenant clusters and restrict git push access to Fleet repositories pending remediation. Within 7 days: apply vendor-released patches per SUSE's version matrix (consult Rancher advisory for your specific release branch); validate patch deployment in non-production environment first. Within 30 days: conduct forensic audit of git push access logs to identify whether the vulnerability was exploited; rotate all secrets and credentials stored in Kubernetes namespaces; implement additional RBAC controls and network policies to limit lateral movement.

Fleet CVE-2026-41050

CRITICAL

Incorrect Authorization (CWE-863)

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

GHSA-765j-qfrp-hm3j

Authentication Bypass Kubernetes Suse

9.9

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

9.9 CRITICAL

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

SUSE

CRITICAL

qualitative

Primary rating from GitHub Advisory.

CVSS VectorGitHub Advisory

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

May 07, 2026 - 01:46 vuln.today

Analysis Generated

May 07, 2026 - 01:46 vuln.today

CVE Published

May 07, 2026 - 01:26 nvd

CRITICAL 9.9

DescriptionGitHub Advisory

Impact

Fleet's Helm deployer did not fully apply ServiceAccount impersonation in two code paths, allowing a tenant with git push access to a Fleet-monitored repository to read secrets from any namespace on every downstream cluster targeted by their GitRepo.

Helm lookup bypass: The Helm template engine ran Kubernetes API queries with the fleet-agent's cluster-admin credentials instead of the impersonated ServiceAccount. A chart template could therefore access resources beyond the tenant's RBAC scope.

valuesFrom bypass: Secret and ConfigMap references in fleet.yaml helm.valuesFrom were read using the fleet-agent's cluster-admin client. A tenant could reference resources in namespaces the impersonated ServiceAccount has no access to. Both issues break Fleet's multi-tenant impersonation boundary. The leaked credentials may belong to external services, making the full impact non-deterministic. Single-tenant deployments where all users are trusted are not affected.

Important:

For the exposure of additional credentials, the final impact severity for confidentiality, integrity and availability is dependent on the permissions the leaked credentials have on their services.
It is recommended to review for potentially leaked credentials in this scenario and to change them if deemed necessary.

Please consult the associated MITRE ATT&CK - Technique - Account Access Removal for further information about this category of attack.

Patches

Both issues are fixed by ensuring the Helm action configuration consistently uses the impersonated ServiceAccount credentials throughout all Helm operations.

Patched versions of Rancher include releases v2.14.1, v2.13.5, v2.12.9, and v2.11.13. For Rancher v2.10.11, users must manually update their Fleet deployment to versionv0.11.13.

Workarounds

No workaround fully mitigates the issue for multi-tenant deployments. The patches should be applied as soon as they are available.

The following measures reduce the attack surface but do not close either vulnerability:

Restrict git push access to Fleet-monitored repositories to trusted users only. In a multi-tenant setup this removes the precondition entirely, but is often not operationally viable.
Use GitRepoRestriction resources to limit which ServiceAccounts each namespace is allowed to use, restricting the set of users who can configure impersonation at all.
Audit deployed chart templates for lookup calls and fleet.yaml files for cross-namespace valuesFrom references as a detective control.

Resources

If there are 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 using the support matrix and product support lifecycle.

AnalysisAI

ServiceAccount impersonation bypass in Rancher Fleet allows tenants with git push access to multi-tenant clusters to read secrets from any namespace across all downstream clusters. Two distinct code paths failed to properly apply RBAC constraints: Helm's lookup function executed with cluster-admin credentials instead of the impersonated ServiceAccount, and valuesFrom secret references in fleet.yaml bypassed namespace isolation. Confirmed active exploitation status unknown (not in CISA KEV). CVSS 9.9 with scope-change modifier reflects potential credential leakage to external services. Fleet versions 0.12.0 through 0.15.0 affected across multiple Rancher release branches. Patches available for all supported versions with detailed version matrix provided by SUSE.

Technical ContextAI

Fleet is Rancher's GitOps continuous delivery tool for Kubernetes, managing Helm chart deployments across multiple clusters. The vulnerability stems from CWE-863 (Incorrect Authorization) in Fleet's Helm deployer integration. In multi-tenant Kubernetes environments, Fleet supports ServiceAccount impersonation to enforce RBAC boundaries - each tenant's GitRepo should execute with their assigned ServiceAccount's limited permissions. However, the RESTClientGetter implementation for Helm operations failed to propagate impersonated credentials in two critical paths: (1) Helm's template rendering engine uses a lookup function to query Kubernetes API during chart evaluation, and this retained the fleet-agent's cluster-admin client; (2) fleet.yaml's helm.valuesFrom mechanism for injecting Secret/ConfigMap data into chart values similarly bypassed the impersonation layer. Both paths allowed authenticated tenants to escalate from their namespace-scoped RBAC to cluster-wide secret read access. The leaked secrets may contain credentials for external systems (databases, cloud APIs, etc.), making the confidentiality/integrity/availability impact dependent on the scope of those credentials. The vulnerability requires Fleet's multi-tenant mode with ServiceAccount impersonation configured - single-tenant deployments where all users share trust boundaries are explicitly unaffected.

RemediationAI

Apply vendor-released patches immediately for multi-tenant deployments: upgrade Rancher to v2.14.1, v2.13.5, v2.12.9, or v2.11.13 depending on current version branch, which will automatically update the embedded Fleet component. For standalone Fleet installations, upgrade directly to Fleet v0.15.1, v0.14.5, v0.13.10, or v0.12.14 as appropriate. Rancher v2.10.11 users must manually update Fleet to v0.11.13 as this version receives only critical security updates. After patching, SUSE strongly recommends reviewing secrets in all namespaces accessible to Fleet for potentially leaked credentials and rotating them if they provide access to sensitive external services - reference MITRE ATT&CK T1531 (Account Access Removal) for credential rotation procedures. Partial mitigations for environments unable to patch immediately: (1) Restrict git push access to Fleet-monitored repositories to fully trusted administrators only, eliminating the threat actor pool but likely operationally infeasible in true multi-tenant scenarios; (2) Deploy GitRepoRestriction resources to limit which ServiceAccounts can be used for impersonation, reducing attack surface by preventing untrusted tenants from configuring impersonation; (3) Implement detective controls by auditing Helm chart templates for lookup function calls and fleet.yaml files for cross-namespace valuesFrom references. Note these workarounds do NOT close the vulnerability and should only be temporary measures pending patch deployment. Full advisory and patch details: https://github.com/rancher/fleet/security/advisories/GHSA-765j-qfrp-hm3j.