Multicluster Engine CVE-2026-73266

Exploitation requires an authenticated tenant account on a Red Hat Multicluster Engine hub (PR:L from CVSS vector) - unauthenticated exploitation is not possible. The deployment must be configured in a multi-tenant model with at least two distinct ManagedClusterSets belonging to different tenants; single-tenant MCE deployments have no foreign ManagedClusterSet to pivot into, making exploitation impact negligible in that configuration. The attacker must know or enumerate the name of a target ManagedClusterSet belonging to another tenant, which contributes to the AC:H rating. The clusterclaims-controller must be active and processing ClusterClaim resources, which is a default component behavior. No user interaction from a privileged user is required (UI:N). Exploitation is limited to tenants who have write access to ClusterClaim resources within their own namespace.

The CVSS 7.1 score is supported by a vector of AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N, which appropriately reflects the scope change (S:C) as the vulnerability crosses tenant isolation boundaries to affect clusters owned by other parties. The AC:H rating is significant: exploitation is not straightforward and likely requires an attacker to understand the specific label schema used by the clusterclaims-controller and have a target ManagedClusterSet identifier - conditions that reduce opportunistic exploitation risk. PR:L confirms a valid tenant credential is required, ruling out unauthenticated attack paths. No EPSS data was provided in the source intelligence, and the vulnerability does not appear in the CISA KEV catalog, indicating no confirmed active exploitation at time of analysis. The real-world risk is highest in shared, multi-tenant MCE deployments - enterprise environments operating multiple business units or customers on a single MCE hub - where the ability to inject policies and workloads into a foreign cluster constitutes a meaningful privilege escalation and potential data exfiltration path. Single-tenant MCE deployments face substantially reduced risk since there are no foreign ManagedClusterSets to pivot into. The high confidentiality impact (C:H) is consistent with the ability to access cluster configuration, secrets, and workloads belonging to another tenant once cluster membership is hijacked.

An authenticated tenant on a shared MCE hub crafts a ClusterClaim resource with labels forged to reference a ManagedClusterSet owned by a separate tenant, then submits it via the standard Kubernetes API. The clusterclaims-controller, acting as a privileged intermediary, processes the label change and moves the targeted cluster into the foreign ManagedClusterSet without validating ownership boundaries. The attacker's tenant can then propagate policies or workloads into that cluster, potentially exfiltrating secrets or disrupting the legitimate tenant's operations. No public proof-of-concept code has been identified, but the attack concept is straightforward for any tenant familiar with MCE's ClusterClaim label schema.