Ce mail provient de l'extérieur, restons vigilants

=====================================================================


                            CERT-Renater

                Note d'Information No. 2026/VULN947
_____________________________________________________________________

DATE                : 29/09/2026

HARDWARE PLATFORM(S): /

OPERATING SYSTEM(S): Systems running rancher/fleet (Go) versions prior
                      to 0.16.2, 0.15.7, 0.14.11, 0.13.16, 0.12.20,
                   Rancher versions prior to 2.15.2, 2.14.6, 2.13.10,
                                   v2.12.14, and v2.11.18.
  
=====================================================================
https://github.com/rancher/fleet/security/advisories/GHSA-q9v4-358v-r8q5
https://github.com/rancher/fleet/security/advisories/GHSA-h9p5-fp5h-qpqr
https://github.com/rancher/fleet/security/advisories/GHSA-wpfm-r97v-3j4h
https://github.com/rancher/fleet/security/advisories/GHSA-m93g-8438-2cgg
https://github.com/rancher/fleet/security/advisories/GHSA-8vfv-33cg-g75q
_____________________________________________________________________

Fleet agent copies downstream resources with cluster-admin privileges,
allowing cross-namespace writes on downstream clusters

Critical
pdellamore published GHSA-q9v4-358v-r8q5 

Package
github.com/rancher/fleet (Go)

Affected versions
>=v0.16.0, <v0.16.2
>=v0.15.0, <v0.15.7
>=v0.14.0, <v0.14.11

Patched versions
v0.16.2
v0.15.7
v0.14.11


Description

Impact

A vulnerability has been identified within Rancher Manager where the
Fleet agent wrote resources to downstream clusters using its own
cluster-admin credentials instead of the ServiceAccount pinned to
the deployment. It affects multi-tenancy environments where different
tenants share the same downstream clusters, for example different
privileged or untrusted teams inside the same organization.

Fleet copies the Secrets and ConfigMaps listed in a Bundle's
downstreamResources from the Bundle's namespace on the management
cluster into the deployment's target namespace on every targeted
downstream cluster. On affected versions where the agent performed
that copy, and created the target namespace when it did not exist
without impersonating the deployment's ServiceAccount, while every
other part of the deployment, including the Helm install and the
namespace creation Helm performs as part of it, was already gated
by that account. The target namespace of a deployment is under the
control of the user who creates the Fleet resource, so these writes
were not confined to the namespaces that user is otherwise entitled
to.

This issue enables a malicious tenant who can create a Bundle,
GitRepo or HelmOp in a Fleet namespace to write or overwrite a Secret
or ConfigMap of any name, with content they control, in any namespace
of every downstream cluster their resource targets, and to have that
namespace created if it does not exist. The previous contents of an
overwritten object are not disclosed, so the impact comes from what
that object is used for: overwriting an image pull secret which can
redirect another tenant's image pulls to a registry the attacker
controls, and overwriting a TLS or database secret, or a ConfigMap
consumed by a co-tenant or a system component, can compromise or
disrupt that workload.

Customers who run Fleet in a multi-tenant environment and cannot rule
out exposure are advised to review the Secrets and ConfigMaps on their
downstream clusters for objects they did not expect, in particular
image pull secrets, and for namespaces that were created unexpectedly.
Objects written by this path carry the label
fleet.cattle.io/bundledeployment, naming the Bundle deployment that
wrote them, which identifies both the objects and the Fleet resource
responsible. Deployments that never became ready should be included in
that review, because the copy happens before the Helm installation.
Rotate any credentials that may have been replaced, and confirm that
workloads pulling images with a reviewed pull secret are running the
images you expect.


Patches

This vulnerability is addressed by performing the downstream writes as
the ServiceAccount pinned to the deployment. Creating the target
namespace and writing the copied Secrets and ConfigMaps now run as that
account, so the tenant's downstream RBAC gates them, in the same way it
already gated the Helm deploy path. Removing the copies again when the
release is deleted remains an agent operation: the objects are selected
by the ownership label Fleet writes on them, so the cleanup only ever
touches objects Fleet created. Reading the source objects still runs as
the agent, because those reads go to the management cluster, where the
downstream ServiceAccount is not a valid identity. When the
ServiceAccount is not allowed to create the namespace or write the
copied objects, the copy is denied before anything is installed, and the
deployment reports “not ready” and retries until the missing permission
is granted.

The protection depends on a ServiceAccount being pinned to the deployment.
When no ServiceAccount resolves, the copy falls back to the agent's own
credentials, which preserves the behavior of existing single-tenant
installations. To benefit from the fix in a multi-tenant setup, pin a
least privilege ServiceAccount and enforce it with a Policy that sets
requireServiceAccount in each tenant namespace, then grant that account
only the namespaces and objects the deployment legitimately writes.

Patched versions of Fleet include releases v0.16.2, v0.15.7, and v0.14.11.

Patched versions of Rancher include releases v2.15.2, v2.14.6 and v2.13.10.


Workarounds

If you can't upgrade to a fixed version, please make sure that you
apply these workarounds:

On Rancher v2.13 and v2.14, leave EXPERIMENTAL_COPY_RESOURCES_DOWNSTREAM
unset or set it to false. The feature is disabled by default on those
releases, and while it is disabled the affected code path does not run at
all, which fully mitigates the issue there.

On all affected releases, restrict through RBAC on the management cluster
who may create or modify Bundle, GitRepo and HelmOp resources in Fleet
namespaces, so that only trusted administrators can reach downstream
clusters this way, and do not let tenants that do not trust each other
share the same downstream clusters. Restricting the tenant's
ServiceAccount on the downstream cluster does not help before the patch,
because the affected path did not use it.


References

    rancher/fleet#5787
    rancher/fleet#5788
    rancher/fleet#5789
    rancher/fleet#5790
    CWE-863: Incorrect Authorization
    CWE-269: Improper Privilege Management

For more information

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 our support matrix and product support life cycle.


Severity
Critical
9.0/ 10

CVSS v4 base metrics
Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements Present
Privileges Required Low
User interaction None
Vulnerable System Impact Metrics
Confidentiality High
Integrity High
Availability High
Subsequent System Impact Metrics
Confidentiality High
Integrity High
Availability High
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

CVE ID
CVE-2026-88808

Weaknesses
Weakness CWE-269
Weakness CWE-863


Credits

    @manus-use manus-use Finder
_____________________________________________________________________


Cross-tenant BundleDeployment and Secret disclosure via spoofed
cluster labels during agent-initiated registration in Fleet

High
pdellamore published GHSA-h9p5-fp5h-qpqr 

Package
github.com/rancher/fleet (Go)

Affected versions
>=v0.16.0, <v0.16.1
>=v0.15.0, <v0.15.6
>=v0.14.0, <v0.14.10
>=v0.13.0, <v0.13.15
>=v0.12.0, <v0.12.19

Patched versions
v0.16.1
v0.15.6
v0.14.10
v0.13.15
v0.12.19


Description

Impact

A cross-tenant authorization issue was discovered in Fleet. During
agent-initiated cluster registration, cluster labels supplied by the
registering agent, including labels in the reservedm
anagement.cattle.io/ namespace such as the cluster display name label,
were applied to the resulting upstream Cluster object. Because Fleet
resolves GitRepo and Bundle targets from those cluster labels, a party
able to register a cluster into a Fleet workspace namespace shared
with other tenants could cause its own cluster to satisfy targeting
rules that administrators intended for a different cluster.

When that happens, Fleet creates a BundleDeployment and the associated
resolved options/values Secret in the registering cluster's own
namespace, where its agent is entitled to read them. The security
outcome is disclosure of another tenant's bundle manifests and of
resolved Helm values, including values sourced through valuesFrom
Secrets, plus deployment of that tenant's intended workload onto a
cluster the other tenant does not control. The victim tenant's own
deployment is not modified or removed.


Preconditions:

Exploitation of this security vulnerability requires the following
conditions:

    The deployment must use agent-initiated cluster registration.
Fleet copies agent-supplied labels only when it creates the Cluster
object as part of that flow.

    Standalone Rancher deployments are not affected in their default
configuration, because Rancher uses manager-initiated registration
and creates the Fleet Cluster object in advance.

    Multiple trust domains must share a single Fleet registration
namespace (for example, several tenants registering into
fleet-default), and the affected Bundle/GitRepo must target clusters
by label or by cluster name.

    IgnoreClusterRegistrationLabels must be left at its default
value of false.


Patches

Fleet now discards reserved label keys supplied by an agent during
agent-initiated cluster registration, so labels in the reserved
management.cattle.io/ namespace, including the cluster display name
label used for name-based targeting, can no longer be self-asserted
by a registering agent. Such labels are only honored when set by the
management plane after registration. Target resolution therefore no
longer matches on values that a registering agent controls.

Patched versions of Fleet include releases v0.16.1, v0.15.6,
v0.14.10, v0.13.15, and v0.12.19.

Patched versions of Rancher include releases v2.15.1, v2.14.5,
v2.13.9, v2.12.13, and v2.11.17.

This change is not expected to be breaking. Environments that
intentionally rely on an agent setting a reserved label at install
time must instead apply that label to the Cluster object from the
management plane after registration.


Workarounds

Organizations that are unable to upgrade immediately, please follow
any of the options below to reduce exposure:

    Use one Fleet workspace per trust domain. Register each tenant's
clusters into a dedicated workspace namespace so that a cluster can
never match another tenant's targets. A shared registration namespace
should be treated as a shared trust domain.

    Disable copying of registration labels. Set
ignoreClusterRegistrationLabels=true (Helm value
ignoreClusterRegistrationLabels on the Fleet controller chart) so
agent-supplied labels are not applied to the Cluster object. Labels
required for targeting must then be applied by an administrator after
registration.

    Use manager-initiated registration. Have the management plane
create the Fleet Cluster object in advance, as Rancher does by default;
agent-supplied labels are not copied in that flow.

    Restrict registration tokens. Treat cluster registration tokens as
sensitive, limit their distribution, and rotate them where they may
have been shared across trust domains.

    Review existing clusters. Inspect Cluster objects in shared workspace
namespaces for unexpected or duplicated reserved labels, in particular
duplicated cluster display name values, and remove any that were not set
by an administrator.


References

    CWE-290: Authentication Bypass by Spoofing
    CWE-639: Authorization Bypass Through User-Controlled Key
    CWE-863: Incorrect Authorization

For more information

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 our support matrix and product support life cycle.


Severity
High
7.1/ 10

CVSS v4 base metrics
Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements Present
Privileges Required Low
User interaction None
Vulnerable System Impact Metrics
Confidentiality High
Integrity Low
Availability None
Subsequent System Impact Metrics
Confidentiality High
Integrity Low
Availability None
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:L/VA:N/SC:H/SI:L/SA:N

CVE ID
CVE-2026-93538

Weaknesses
Weakness CWE-290
Weakness CWE-639
Weakness CWE-863

Credits

    @Pig-Tail Pig-Tail Finder

_____________________________________________________________________

Path traversal in Fleet Helm valuesFiles allows disclosure of files
outside the bundle directory

High
pdellamore published GHSA-wpfm-r97v-3j4h 

Package
github.com/rancher/fleet (Go)

Affected versions
>=v0.16.0, <v0.16.2
>=v0.15.0, <v0.15.7
>=v0.14.0, <v0.14.11
>=v0.13.0, <v0.13.16
>=v0.12.0, <v0.12.20

Patched versions
v0.16.2
v0.15.7
v0.14.11
v0.13.16
v0.12.20


Description

Impact

A security vulnerability was discovered in Fleet's handling of the
Helm valuesFiles setting in fleet.yaml. Entries in that list were not
confined to the bundle directory, so a bundle could reference files
located outside the Git repository content that Fleet checked out.

A user who can supply bundle content to a repository referenced by a
GitRepo resource, for example through Git push access, or through
permission to create or modify a GitRepo, can cause Fleet to read
files from the filesystem of the environment that processes the
bundle and include their contents in the generated Bundle resource.
This can expose configuration or credential material that the user
has no Kubernetes RBAC permission to read, including Helm registry
credentials made available to the bundle-processing job when
per-path Helm credentials are configured.

Disclosure is limited to files whose contents parse as a YAML or
JSON mapping. Integrity and availability of managed clusters are
not affected.


Preconditions

Exploitation of this security vulnerability requires the following
conditions:

    Fleet must reconcile a GitRepo whose bundle content is not
fully trusted, for example when repository write access extends
beyond the administrators of the management cluster, or when users
may create their own GitRepo resources.

    Only bundles that use Helm valuesFiles
(including targetCustomizations[].helm.valuesFiles) are affected.

Note

The highest confidentiality impact applies where the affected GitRepo
uses per-path Helm credentials (helmSecretNameForPaths), because that
credential material is made available to the bundle-processing job.


Patches

The fix constrains Helm valuesFiles entries to the bundle directory.
Paths that resolve outside the bundle root are rejected before any
file is read, and the affected GitRepo reports an error instead ofp
roducing a bundle. This is a behavior change for bundles that relied
on referencing values files outside the bundle directory; such bundles
must be updated to keep their values files inside the bundle directory.

Patched versions of Fleet include releases v0.16.2, v0.15.7, v0.14.11,
v0.13.16, and v0.12.20.

Patched versions of Rancher include releases v2.15.2, v2.14.6,
v2.13.10, v2.12.14, and v2.11.18.


Workarounds

No workaround exists other than upgrading to a patched version.
Organizations unable to upgrade immediately can reduce exposure
by:

    Restricting write access to repositories referenced by Fleet
GitRepo resources to trusted administrators.

    Restricting, through RBAC, which users may create or modifyG
itRepo resources, so that only reviewed repositories are
reconciled.

    Reviewing bundles for helm.valuesFiles entries that point
outside the bundle directory.

    Limiting the use of per-path Helm credentials
(helmSecretNameForPaths) to GitRepo resources whose content is
fully trusted.


References

    CWE-22: Improper Limitation of a Pathname to a Restricted
Directory

    CWE-200: Exposure of Sensitive Information to an
Unauthorized Actor


For more information

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 our support matrix and product support life cycle.


Severity
High
7.0/ 10

CVSS v4 base metrics
Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements Present
Privileges Required Low
User interaction None
Vulnerable System Impact Metrics
Confidentiality High
Integrity None
Availability None
Subsequent System Impact Metrics
Confidentiality High
Integrity None
Availability None
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N

CVE ID
CVE-2026-93537

Weaknesses
Weakness CWE-22
Weakness CWE-200

Credits

    @Pig-Tail Pig-Tail Finder

_____________________________________________________________________


Fleet applies namespace labels and annotations without the bundle's
service account privileges

High
pdellamore published GHSA-m93g-8438-2cgg 

Package
github.com/rancher/fleet

Affected versions
>=v0.16.0, <v0.16.1
>=v0.15.0, <v0.15.7
>=v0.14.0, <v0.14.11
>=v0.13.0, <v0.13.16

Patched versions
v0.16.1
v0.15.7
v0.14.11
v0.13.16


Description
Impact

A privilege mismatch was found in Fleet. When a bundle requested
namespace labels or annotations through the namespaceLabels and
namespaceAnnotations options, the resulting namespace metadata
update was not subject to the same authorization as the rest of the
bundle's deployment. As a result, a bundle could change labels and
annotations on a target namespace even when the identity it was
pinned to was not authorized to modify that namespace.

In multi-tenant deployments, namespace labels and annotations are
frequently consumed by cluster-level controllers and policy engines,
so unauthorized changes to them can weaken the security posture an
administrator configured for a namespace. The issue does not expose
confidential data and does not directly affect the availability of
running workloads.

Note: Only deployments that rely on Fleet's multi-tenant model are
affected, that is, deployments where bundles are pinned to a service
account either directly on the bundle or through a Policy with
requireServiceAccount and allowedServiceAccounts. In operator mode,
where no service account is pinned, bundles deploy with the Fleet
agent's own credentials by design and this authorization boundary
does not apply.


Patches

The namespace update that applies namespaceLabels and
namespaceAnnotations after a deployment now runs as the deployment's
service account, resolved through the same impersonation path already
used for the deployment itself. Reads and updates of the target
namespace are therefore gated by the same downstream Kubernetes RBAC
as every other action the bundle performs. There is no longer a
configuration in which the deployment is impersonated but the
namespace metadata update is not.

In a follow-up change, the previously introduced
pod-security.kubernetes.io/ label filter was removed in Fleet v0.16.2,
v0.15.7, v0.14.11, and v0.13.16. That filter prevented operators from
legitimately setting Pod Security Standards labels through
namespaceLabels; the authorization decision is now made by cluster
RBAC instead of by a prefix blocklist. No equivalent annotation
blocklist was added, for the same reason.

Upgrade action: In multi-tenant deployments, a bundle that previously
relied on Fleet's elevated credentials to set namespace labels or
annotations will now fail if its pinned service account lacks get and
update permissions on the target namespace. Administrators should
either pre-create and configure such namespaces themselves, or
explicitly grant the tenant service account the required namespace
permissions if tenants are intended to control namespace metadata.

Patched versions of Fleet include releases v0.16.1, v0.15.7,
v0.14.11, and v0.13.16.

Patched versions of Rancher include releases v2.15.1, v2.14.6,
v2.13.10, and v2.12.14.


Workarounds

For users who cannot upgrade to a patched version:

    Restrict who can deploy through Fleet. On affected versions,
the service account a bundle is pinned to does not limit
namespace label and annotation changes, so restricting that
service account's permissions does not mitigate this issue.
Limit permission to create or modify GitRepo, HelmOp, and Bundle
resources, and control which git repositories and Helm sources
Fleet is configured to use, so that only trusted content reaches
a cluster.

    Block namespace metadata changes by the Fleet agent. On
affected versions, the namespace update is made with the Fleet
agent's own identity, not with the tenant's service account. An
admission or policy controller can reject or alert on label and
annotation changes on tenant namespaces made by that identity:

        system:serviceaccount:cattle-fleet-system:fleet-agent on
downstream clusters

        system:serviceaccount:cattle-fleet-local-system:fleet-agent
on the Rancher local cluster


    Bundles that legitimately use namespaceLabels or
namespaceAnnotations on those namespaces will fail to deploy while
such a policy is in place. In Rancher, the rancher-webhook
updatepsa check does not prevent this issue on affected versions,
because the Fleet agent's identity passes that check.

After upgrading, verify that tenant service accounts only hold
the namespace permissions you intend, for example:

kubectl auth can-i update namespaces \
  --as=system:serviceaccount:<agent-namespace>:<tenant-service-account>


References

    rancher/fleet#5351 (main)
    rancher/fleet#5415 (release/v0.16)
    rancher/fleet#5657 (release/v0.15)
    rancher/fleet#5662 (release/v0.14)
    rancher/fleet#5663 (release/v0.13)
    CWE-269: Improper Privilege Management
    CWE-863: Incorrect Authorization

For more information

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 our support matrix and product support life cycle.


Severity
High
7.1/ 10

CVSS v4 base metrics
Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements None
Privileges Required Low
User interaction None
Vulnerable System Impact Metrics
Confidentiality None
Integrity High
Availability None
Subsequent System Impact Metrics
Confidentiality None
Integrity None
Availability None
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

CVE ID
CVE-2026-93540

Weaknesses
Weakness CWE-269
Weakness CWE-863

Credits

    @manus-use manus-use Finder

_____________________________________________________________________


Unauthenticated GitRepo Spec Mutation via Fleet Git Webhook Receiver
Moderate
pdellamore published GHSA-8vfv-33cg-g75q 

Package
github.com/rancher/fleet

Affected versions
>=v0.16.0, <v0.16.2

Patched versions
v0.16.2


Description

Impact

A vulnerability was discovered in Fleet's Git webhook receiver (the
gitjob webhook service). When a webhook secret is not configured,
incoming webhook requests are accepted without verification, and
processing a request can change the spec.pollingInterval field of a
matching GitRepo resource in any namespace. A caller with network
access to the webhook service and no Kubernetes credentials can
therefore alter GitRepo configuration outside the namespaces they
are authorized for.

The practical impact is limited to integrity and availability of Fleet's
Git polling behavior: the affected GitRepo has its polling interval set
to one hour, which can delay the rollout of legitimate Git changes, and
each request causes additional Git operations against the configured
Git host. The content that Fleet deploys is not affected, because the
controller always re-resolves the actual remote commit before
deploying, and no data is disclosed.

Note: Only deployments where the webhook secret is not in use are
affected. Fleet does not configure a webhook secret by default: the
Fleet Helm chart does not create the global gitjob-webhook Secret,
and GitRepo.spec.webhookSecret is empty unless explicitly set.
Deployments that configure a webhook secret are not affected,
because unverified requests are rejected in that case.

Only Fleet v0.16.0 and v0.16.1 (shipped with release line Rancher
v2.15.0 and v2.15.1 respectively) are affected. Earlier Fleet
release lines do not perform this spec mutation and were verified
as not vulnerable.


Patches

Fleet now confines the webhook-triggered mutation of GitRepo.spec
to requests that have been successfully verified against either
GitRepo.spec.webhookSecret or the global gitjob-webhook Secret.
Unverified requests can no longer set the default polling interval
on a GitRepo. This is not a breaking change and no manual action
is required after upgrading, beyond the upgrade itself.

Patched versions of Fleet include release v0.16.2.

Patched versions of Rancher include release v2.15.2, all other
release lines are unaffected.


Workarounds

For users who cannot upgrade immediately:

    Configure a webhook secret. Set a secret for the Git webhook
receiver, either per repository through GitRepo.spec.webhookSecret
or globally through the gitjob-webhook Secret in the Fleet controller
namespace (cattle-fleet-system by default). When a secret is present,
unverified webhook requests are rejected.

    Set an explicit polling interval. Setting spec.pollingInterval
explicitly on each GitRepo prevents the value from being changed
through this path.

    Restrict network access to the webhook service. If the Git webhook
receiver is not used, do not expose the gitjob service outside the
cluster, and apply a NetworkPolicy restricting access to the webhook
port to trusted sources only. When the receiver is used, place it
behind an authenticated or source-restricted ingress.


References

    rancher/fleet#5781
    rancher/fleet#5782
    CWE-306: Missing Authentication for a Critical Function
    CWE-862: Missing Authorization

For more information

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 our support matrix and product support life cycle.


Severity
Moderate
6.3/ 10

CVSS v4 base metrics
Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements Present
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality None
Integrity Low
Availability Low
Subsequent System Impact Metrics
Confidentiality None
Integrity Low
Availability Low
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:L/SC:N/SI:L/SA:L

CVE ID
CVE-2026-93539

Weaknesses
Weakness CWE-306
Weakness CWE-862

Credits

    @Pig-Tail Pig-Tail Finder



=========================================================
+ CERT-RENATER        |    tel : 01-53-94-20-44         +
+ 23/25 Rue Daviel    |    fax : 01-53-94-20-41         +
+ 75013 Paris         |   email:cert@support.renater.fr +
=========================================================