Open Cluster Management: forged client certificate lets a managed-cluster admin pivot to the hub

Impact

OCM does not properly validate Kubernetes client certificate renewal, so an administrator of one managed cluster can forge a client certificate that the OCM controller will approve. Red Hat describes the result as cross-cluster privilege escalation, potentially reaching other managed clusters and the hub cluster itself. In a fleet where one ACM hub drives many GPU clusters — often one per tenant, team or region — this collapses the boundary the hub exists to enforce: an admin on the least important spoke gets to place workloads, read secrets and change policy on every other cluster the hub manages. Recovery is not just a patch, because any certificate issued during the exposure window has to be treated as suspect.

Who can reach it

An authenticated administrator of any cluster already registered to the hub. No unauthenticated or tenant-pod path; the attacker must already hold admin on one managed cluster.

What to do

Red Hat has shipped errata for multicluster engine 2.6 through 2.11 (RHSA-2026:8218, 9848, 11414, 13542, 13853) — apply the one matching your MCE/ACM stream. The upgrade rolls the hub-side controller pods; managed clusters keep running workloads through it, but registration and policy reconciliation pause during the rollout. Afterwards, review approved CSRs on the hub for certificates you did not expect.

References