RHACM cluster-proxy: caller-supplied impersonation headers grant cluster-admin on managed clusters

Impact

service-proxy appends its own impersonation group headers without stripping the ones the caller sent, and the spoke ServiceAccount it proxies as holds unrestricted impersonation rights. An authenticated principal on the hub can therefore set Impersonate-Group and act as cluster-admin on every managed cluster attached to that hub. For a fleet operator this is the worst shape of a control-plane bug: one hub credential becomes full administrative control of all spokes at once - node pools, GPU Operator and device-plugin configuration, every tenant namespace, and every secret in them. Red Hat rates it CVSS 8.5 with scope change and high attack complexity.

Who can reach it

An authenticated hub principal - any account with credentials on the RHACM/MCE hub that can drive a proxied request. No access to the managed clusters themselves is needed; the proxy supplies that.

What to do

Apply the RHSA errata listed for your multicluster-engine and RHACM stream (RHSA-2026:46885 / 47388 / 47735 / 47949 / 47953). The fix ships as updated operator images, so the rollout is a hub-side operator upgrade and a restart of the cluster-proxy/service-proxy pods - no node drain and no spoke reboot. Until it lands, tighten who holds credentials on the hub and audit spoke API audit logs for requests carrying Impersonate-Group.

References