Introduction
A flaw in how Open Cluster Management validates Kubernetes client certificate renewals lets an administrator of one managed cluster forge credentials and escalate privileges across the cluster fleet, including the hub cluster itself. The vulnerability has a CVSS score of 8.2, and a public writeup details the full exploitation method. Organizations running Red Hat Advanced Cluster Management or Multi Cluster Engine need to evaluate it immediately.
Open Cluster Management (OCM) is an open-source CNCF project 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's responsibilities include 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 is in the logic that validates CertificateSigningRequest (CSR) approvals in the OCM operator on the hub cluster. In OCM's architecture, agents on managed clusters authenticate to the hub with Kubernetes client certificates. When a certificate needs renewal, the agent submits a CSR to the hub, and a controller decides whether to approve it.
The flaw, classified as CWE-295 (Improper Certificate Validation), is in how this controller validates the request. The code relies on a user-defined label to calculate the server name, and it only verifies that the prefix of the server name in the certificate's common name matches the server name in the group. The validation does not require 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." That makes the hub a natural target for any attacker whose cluster name begins with that string.
Exploitation Flow
The attack has five stages:
-
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.
-
The attacker creates a new CertificateSigningRequest with a custom group that targets a victim cluster. For the prefix validation to succeed, the victim cluster must share a name prefix with the attacker's cluster.
-
The attacker submits the CSR to the Kubernetes API on the hub. The OCM controller evaluates the request, sees that the prefix of the server name matches, and automatically approves the forged certificate.
-
Using 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.
-
The patched ManifestWork deploys a ClusterRoleBinding to the victim cluster that grants the attacker full administrator rights on that cluster.
Constraints and Scope
Exploitation depends on several conditions:
| 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 |
Bootstrap tokens expire after one year by default, which 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 because it depends directly on OCM.
- Red Hat Multi Cluster Engine for Kubernetes: Affected because it depends directly on OCM.
Hypershift-hosted clusters are explicitly noted as not impacted, because their architecture does not expose agent secrets to managed cluster administrators.
