CVE-2026-17107: Red Hat RHACM Privilege Escalation Flaw

CVE-2026-17107 Overview

CVE-2026-17107 is an authorization bypass in the cluster-proxy service-proxy component shipped with Red Hat Advanced Cluster Management for Kubernetes (RHACM) and multicluster-engine (MCE). The service-proxy appends impersonation group headers to proxied requests without stripping caller-supplied values. Because the spoke ServiceAccount holds unrestricted impersonation permissions, an authenticated hub principal can inject an Impersonate-Group header and escalate to cluster-admin on every managed cluster. The flaw is tracked under CWE-441: Unintended Proxy or Intermediary.

Critical Impact
Any authenticated hub user can escalate to cluster-admin across every managed spoke cluster, resulting in full loss of confidentiality, integrity, and availability of workloads.

Affected Products

Red Hat Advanced Cluster Management for Kubernetes (RHACM)
Red Hat multicluster-engine (MCE)
cluster-proxy service-proxy component

Discovery Timeline

2026-07-24 - CVE-2026-17107 published to NVD
2026-07-30 - Last updated in NVD database

Technical Details for CVE-2026-17107

Vulnerability Analysis

The cluster-proxy service-proxy sits between the RHACM hub cluster and each managed (spoke) cluster. It forwards Kubernetes API requests from hub-side users to the spoke API server using a service account with wide privileges. To carry hub identity across the tunnel, the proxy attaches Impersonate-User and Impersonate-Group headers before forwarding the request.

The component fails to sanitize inbound requests. When a hub principal supplies its own Impersonate-Group header, the proxy does not remove that header before appending its own. The spoke API server receives both sets of headers and processes the caller-controlled group value. Because the spoke ServiceAccount is granted unrestricted impersonation via a permissive RBAC binding, the API server honors any group the attacker specifies, including system:masters.

Root Cause

The root cause is two-fold. First, the proxy trusts client-controlled impersonation headers instead of stripping them at the boundary. Second, the spoke service account is bound to a role that permits impersonation of arbitrary users and groups, violating least privilege. Together these conditions collapse the trust boundary the proxy is meant to enforce.

Attack Vector

An attacker needs valid hub credentials with permission to reach a proxied service endpoint. The attacker sends an HTTP request to the hub-exposed proxy path and includes a crafted Impersonate-Group: system:masters header. The proxy forwards the request to the spoke cluster along with its own impersonation headers. The spoke API server treats the attacker as a member of system:masters, granting cluster-admin on that managed cluster. The exploitation code example is not published; refer to the Red Hat CVE Analysis for CVE-2026-17107 for technical details.

Detection Methods for CVE-2026-17107

Indicators of Compromise

Requests to cluster-proxy endpoints containing client-supplied Impersonate-User, Impersonate-Group, or Impersonate-Extra-* headers.
Spoke kube-apiserver audit events showing impersonation as system:masters or other high-privilege groups originating from the cluster-proxy service account.
Unexpected RoleBinding, ClusterRoleBinding, or ServiceAccount creation on managed clusters shortly after proxied API traffic.

Detection Strategies

Enable Kubernetes audit logging on every managed cluster and alert on any impersonatedUser.groups value containing system:masters or cluster-admin.
Inspect ingress logs and service mesh telemetry at the hub for inbound Impersonate-* headers on cluster-proxy routes.
Correlate hub identity (user.username) with spoke-side impersonation events to detect identity mismatches across the tunnel.

Monitoring Recommendations

Baseline normal impersonation patterns from cluster-proxy service accounts and alert on deviations.
Monitor for privileged workload creation, secret access, and RBAC changes on spoke clusters immediately following hub proxy traffic.
Track version and patch state of RHACM and MCE deployments continuously to confirm remediated builds are running.

How to Mitigate CVE-2026-17107

Immediate Actions Required

Apply the Red Hat errata listed below to every RHACM hub and MCE deployment as soon as maintenance windows allow.
Rotate any credentials or tokens that may have been exposed through proxied requests during the vulnerable window.
Audit spoke clusters for unauthorized RBAC changes, service accounts, or workloads created since the component was deployed.

Patch Information

Red Hat has released fixes across multiple advisories. Apply the update that matches your channel: RHSA-2026:46885, RHSA-2026:47388, RHSA-2026:47735, RHSA-2026:47949, RHSA-2026:47953, RHSA-2026:47974, and RHSA-2026:48284. See the Red Hat CVE Analysis for CVE-2026-17107 and Red Hat Bug Report #2506771 for scope and affected component versions.

Workarounds

Restrict hub-side access to cluster-proxy endpoints to a minimal set of trusted administrators until patches are applied.
Tighten the spoke ServiceAccount RBAC binding so impersonation is scoped to specific users and groups rather than unrestricted.
Deploy an ingress-layer filter that strips inbound Impersonate-User, Impersonate-Group, and Impersonate-Extra-* headers before requests reach the proxy.

bash

# Configuration example not published by the vendor; refer to Red Hat advisories for authoritative remediation steps.