Multi-cluster Kubernetes management tools exist to give one team a single point of control over many clusters, which is exactly what made this flaw so damaging: it turned that single point of control into a single point of failure.
A confused-deputy bug in the impersonation logic
Rancher supports Kubernetes API impersonation through headers like Impersonate-User, Impersonate-Group and Impersonate-Extra-*, letting the platform act on a user’s behalf against a specific downstream cluster. CVE-2026-44945, tracked as GHSA-v584-7w32-jwpq and scored 9.1, sits in pkg/auth/requests/impersonate.go and is a textbook confused-deputy weakness (CWE-441): Rancher parsed a cluster identifier from the request URL, ran a Kubernetes SubjectAccessReview against that specified downstream cluster to check authorization, and then handed the request to Rancher’s management API, which executes using the privileged scaledContext service account against Rancher’s own local cluster, not the one that was checked.
Why a default permission was enough to exploit it
The practical severity comes from what an attacker needed to trigger it: an authenticated Rancher session with the default user global role, RBAC permission on at least one downstream cluster, and the standard, low-privilege ability to register a new downstream cluster. Registering a cluster is something most Rancher users can already do, and nothing stops that cluster from being a throwaway k3d, kind, or minikube instance the attacker fully controls. By crafting impersonation headers to claim privileged identities, including system:masters, against Rancher’s local cluster while the authorization check ran against their own disposable cluster, an attacker could escalate from an ordinary account to full administrative control over Rancher and every cluster it manages.
Patch now, the workaround only closes part of the gap
Fixed versions are 2.11.16, 2.12.12, 2.13.8 and 2.14.4, covering the 2.11.0, 2.12.0, 2.13.0 and 2.14.0 release lines respectively. Rancher has published a partial mitigation restricting which users can register downstream clusters, but the advisory is clear that this does not fully eliminate the risk, it only narrows who can attempt it. Any team that cannot restrict cluster registration to a small, trusted group should treat patching as the only real fix.
What this means for European Kubernetes operators
Rancher is widely deployed by European teams specifically to keep multi-cluster management, and the credentials that go with it, inside infrastructure they control rather than a hyperscaler-managed control plane. This flaw is a reminder that centralising control over many clusters in one platform also centralises the blast radius of a single logic bug in that platform. Anyone running Rancher for regulated workloads under NIS2 or DORA should confirm which version is deployed today, not assume a recent upgrade already covers it, and audit who currently holds the ability to register a downstream cluster.
If you need help confirming whether your Rancher deployment is exposed, auditing RBAC around cluster registration, or reviewing how much blast radius a single compromised account has across your Kubernetes estate, contact Excello Digital. We help European teams run multi-cluster infrastructure without one bug in the control plane becoming a takeover of everything it manages.