RHACM cluster-proxy CVE-2026-17107

Exploitation requires an authenticated principal on the hub cluster with at least low-level access sufficient to route requests through the cluster-proxy service-proxy endpoint. The vulnerability is gated on: (1) the target environment running RHACM or MCE with the cluster-proxy component deployed and active; (2) the attacker having valid credentials for the hub cluster (PR:L - unauthenticated exploitation is not possible); (3) the attacker being able to reach the cluster-proxy API endpoint on the hub (network access, AV:N). The AC:H rating reflects that the attacker must understand the proxy routing mechanism and construct a valid proxied request to a spoke cluster endpoint. The spoke ServiceAccount's unrestricted impersonation permissions are a necessary structural prerequisite - environments that have already scoped down the spoke impersonation ClusterRoleBinding would significantly limit impact. This vulnerability does not affect environments that have not deployed RHACM or MCE, and it does not affect hub-internal resources - only resources on managed spoke clusters.

Despite a moderate CVSS base score of 8.5 (High), the real-world impact warrants elevated organizational priority for RHACM/MCE operators. The CVSS vector (AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H) correctly captures that authentication is required (PR:L) and some complexity exists (AC:H), likely reflecting the need to route requests through the specific proxy endpoint. The Changed Scope (S:C) with C:H/I:H/A:H reflects total compromise of every managed cluster, not merely the hub - a single low-privilege hub account can laterally compromise an entire enterprise cluster fleet. EPSS at 0.23% (14th percentile) and SSVC Exploitation:none both indicate no observed exploitation, and SSVC Automatable:no aligns with AC:H (crafting the attack requires knowing the proxy routing). However, SSVC Technical Impact:total and the scope-change impact metrics mean that once exploited, recovery requires auditing and remediating every managed cluster. The primary limiting factor is that the attacker must already hold authenticated access to the hub - insider threat or compromised hub credentials represent the realistic threat model. No KEV listing and no POC confirm this remains a patch-and-move-on risk rather than an emergency breakglass scenario for most operators.

An attacker with low-privilege authenticated access to the hub cluster (e.g., a developer account with namespace-scoped permissions) sends an API request to the cluster-proxy service-proxy endpoint targeting a managed spoke cluster, injecting the HTTP header Impersonate-Group: system:masters. The proxy appends its own impersonation context but does not strip the caller-supplied header, so the forwarded request arrives at the spoke cluster's API server carrying system:masters group membership. The spoke ServiceAccount's unrestricted impersonation ClusterRoleBinding causes the spoke API server to honor the escalated identity, granting the attacker cluster-admin on that spoke - and by repeating across all spokes, on every managed cluster. No POC has been publicly confirmed at time of analysis.