SUSE Rancher Fleet EUVD-2026-114135

Exploitation requires that the actor already holds a valid Fleet registration token for the workspace in which the target cluster is registered, and that they know the target cluster's client identifier (a stable, non-secret value, typically obtained via read access to Cluster resources). Cross-tenant impact additionally requires a shared Fleet workspace where clusters of different tenants are registered together - this is the default single-workspace model. Limiting factors: it cannot be performed by a fully unauthenticated outsider (a workspace registration token is needed), deployment content itself cannot be modified, and clusters that use a kubeConfigSecret are unaffected because they use their import token and ignore any leftover registration-token annotation. There is no workaround other than upgrading; exposure can be reduced by isolating tenants into separate workspaces/tokens, tightly RBAC-restricting ClusterRegistrationToken creation/read and keeping TTLs short, restricting read access to Cluster resources, and monitoring for unexpected ClusterRegistration objects or agents that lose credentials.

This is a genuine but conditional multi-tenant privilege/identity issue rather than a broadly remotely-exploitable flaw. The CVSS 3.1 vector (AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:L/A:H, base 7.9) already encodes that exploitation requires privileges (PR:H) - namely a valid Fleet registration token - and the scope change (S:C) reflects that the attacker reaches another cluster's Fleet management namespace. KEV status is NO (not listed as actively exploited by CISA), no EPSS score was supplied, and the only reference is the vendor GHSA advisory, so there is no public exploit identified at time of analysis. SSVC-style signals (automatable, technical-impact) were not provided in structured form; the vuln.today Decision label is 'this_week', which is a prioritize-promptly tier, not 'act_now'/'emergency'. The practical limiter is architectural: the attacker must already be a legitimate token-holder in a shared Fleet workspace and must know the target cluster's (non-secret) client identifier, so realistic exploitation looks like a malicious or compromised tenant inside a shared single-workspace deployment, i.e. targeted/insider abuse rather than mass internet exploitation. Net: a real, worth-patching cross-tenant authentication-binding weakness, but not an emergency drop-everything item absent KEV/EPSS evidence of active or automatable exploitation.

In a shared Fleet workspace hosting clusters from multiple tenants (the default single-workspace model), an actor holding a valid registration token for that workspace learns the stable, non-secret client identifier of another tenant's cluster. They submit a registration request claiming that cluster's identity; because identity was accepted without being bound to the originating registration token, Fleet issues credentials scoped to the victim cluster's Fleet management namespace, letting them read synced Secrets and ConfigMaps and disrupt the legitimate agent. No public exploit code is identified at time of analysis; the only reference is the vendor GHSA advisory.