Introduction
A flaw in how Open Cluster Management validates Kubernetes client certificate renewals allows an administrator of one managed cluster to forge credentials and escalate privileges across the entire cluster fleet, including the hub cluster itself. With a CVSS score of 8.2 and a public writeup detailing the full exploitation methodology, this is a vulnerability that organizations running Red Hat Advanced Cluster Management or Multi Cluster Engine need to evaluate immediately.
Open Cluster Management (OCM) is an open source CNCF project that provides the foundational technology for managing fleets of Kubernetes clusters through a hub and spoke model. It underpins Red Hat's commercial Advanced Cluster Management (ACM) and Multi Cluster Engine products, which are widely deployed in enterprise hybrid cloud environments. The project handles critical operations including cluster registration, workload distribution via ManifestWork resources, and certificate based authentication between hub and managed clusters.
Technical Information
Root Cause: Prefix Based Certificate Validation
The vulnerability resides in the validation logic for CertificateSigningRequest (CSR) approvals within the OCM operator running on the hub cluster. In OCM's architecture, agents on managed clusters authenticate to the hub using Kubernetes client certificates. When these certificates need renewal, the agent submits a CSR to the hub, and a controller evaluates whether to approve it.
The flaw, classified as CWE-295 (Improper Certificate Validation), is in how this controller performs its validation. The code relies on a user defined label to calculate the server name and only verifies that the prefix of the server name in the certificate's common name matches the server name in the group. This means the validation does not enforce an exact match between the requesting cluster's identity and the cluster name embedded in the certificate.
An attacker who controls a managed cluster named, for example, "local cluster example" can craft a CSR with a group name that shares the prefix "local cluster" and the controller will approve it. This is especially dangerous because the default hub cluster in OpenShift is named "local cluster," making it a natural target for any attacker whose cluster name begins with that string.
Exploitation Flow
The attack proceeds through five distinct stages:
-
Secret Extraction: The attacker, who holds administrator privileges on a managed cluster, extracts the hub kubeconfig secret from the agent namespace. This secret contains the credentials the agent uses to communicate with the hub.
-
CSR Crafting: The attacker creates a new CertificateSigningRequest with a custom group targeting a victim cluster. The victim cluster must share a name prefix with the attacker's cluster for the prefix validation to succeed.
-
Automatic Approval: The attacker submits the CSR to the Kubernetes API on the hub. The OCM controller evaluates the request, and because the prefix of the server name matches, it automatically approves the forged certificate.
-
ManifestWork Manipulation: Armed with the forged certificate, the attacker patches a ManifestWork resource on the hub cluster. ManifestWork is the mechanism OCM uses to distribute Kubernetes resources to managed clusters.
-
Privilege Escalation: The patched ManifestWork deploys a ClusterRoleBinding to the victim cluster, granting the attacker full administrator rights on that cluster.
Constraints and Scope
Several conditions must be met for successful exploitation:
| Constraint | Detail |
|---|---|
| Initial Access | The attacker must already have administrator access to one managed cluster to read agent secrets |
| Naming Requirement | Only clusters sharing a name prefix with the attacker's cluster can be targeted |
| Network Access | The attacker needs network connectivity to the victim cluster's API |
| Hypershift Exception | Hypershift hosted clusters are not impacted because their agents run directly on the hub without exposing secrets |
The default one year expiration on bootstrap tokens gives attackers a substantial window to enumerate cluster names and attempt prefix based forgery across the fleet.
Affected Systems and Versions
The following products are affected:
- Open Cluster Management (OCM): All versions released over the past two years according to the security researcher's disclosure.
- Red Hat Advanced Cluster Management for Kubernetes: Affected due to its direct dependency on OCM.
- Red Hat Multi Cluster Engine for Kubernetes: Affected due to its direct dependency on OCM.
Hypershift hosted clusters are explicitly noted as not impacted because their architecture does not expose agent secrets to managed cluster administrators.
