Multicluster Engine CVE-2026-66795

Exploitation requires the attacker to already control a privileged service account on a registered spoke (managed) cluster within an MCE/RHACM hub-and-spoke deployment, and the vulnerable managedcluster-import-controller CSR auto-approval path must be in use (default in MCE-managed import flows). The forged CSR succeeds specifically because the controller does not validate the signer name and does not decode/inspect the PEM x509 CSR. Limiting factors: this is not exploitable by an unauthenticated or fully external attacker - CVSS PR:L reflects the required privileged spoke identity - so risk is bounded by how tightly privileged service accounts and cluster imports are controlled; it does not affect standalone Kubernetes/OpenShift clusters that are not enrolled as spokes under MCE.

Signals are mixed and worth weighing carefully. CVSS 3.1 is 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) - network vector, low complexity, only low privileges, no user interaction, and a scope change reflecting the spoke-to-hub pivot with total confidentiality, integrity, and availability impact. Against that, EPSS is only 0.22% (12th percentile) and CISA's SSVC decision records Exploitation: none and Automatable: no, while Technical Impact: total agrees with the CVSS impact metrics. There is no KEV listing and no public PoC. The reconciling read: the technical impact if exploited is catastrophic (hub takeover across a managed fleet), but exploitation is gated behind already holding a privileged service account on a spoke cluster, which is a meaningful barrier and explains the low, non-automatable exploitation likelihood. This is a genuine high-priority patch for anyone running MCE/RHACM at scale - the blast radius is fleet-wide - but it is not a spray-and-pray internet threat; realistic risk is highest in multi-tenant or lower-trust spoke environments where a spoke compromise is plausible.

An attacker who has compromised a workload or otherwise controls a privileged service account on a managed spoke cluster crafts a malicious CSR and submits it to the hub. Because the import controller auto-approves without checking the signer name or decoding the x509 request, the CSR is signed and the attacker receives a certificate granting administrative identity on the hub cluster, from which they control every managed cluster. No public PoC is known, but the low attack complexity means a spoke foothold is the only substantial prerequisite.