CVE-2026-4740: Red Hat ACM Privilege Escalation Flaw

CVE-2026-4740 Overview

CVE-2026-4740 is an improper certificate validation flaw [CWE-295] in Open Cluster Management (OCM), the upstream project for Red Hat Advanced Cluster Management for Kubernetes (ACM). The OCM controller fails to properly validate Kubernetes client certificate renewal requests. A managed cluster administrator can forge a client certificate that the controller will approve. The forged certificate enables cross-cluster privilege escalation, allowing an attacker to pivot from one managed cluster to other managed clusters and ultimately the hub cluster.

Critical Impact

An authenticated administrator of a single managed cluster can escape isolation boundaries and gain control over the hub cluster and every other managed cluster in the fleet.

Affected Products

• Red Hat Advanced Cluster Management for Kubernetes
• Open Cluster Management (OCM) upstream project
• Multi-cluster Kubernetes deployments using OCM hub-spoke architecture

Discovery Timeline

• 2026-04-07 - CVE-2026-4740 published to the National Vulnerability Database
• 2026-04-28 - Last updated in NVD database

Technical Details for CVE-2026-4740

Vulnerability Analysis

Open Cluster Management uses a hub-spoke architecture. The hub cluster manages many spoke clusters through a registration agent that authenticates using mutual TLS. Each managed cluster receives a client certificate signed by the hub. The hub periodically renews these certificates through Kubernetes CertificateSigningRequest (CSR) resources approved by the OCM registration controller.

The vulnerability stems from insufficient validation logic in the certificate renewal approval path. The controller does not properly verify the binding between the renewal request and the original certificate subject. A managed cluster administrator can craft a CSR that requests a certificate with a subject or group claim belonging to a different managed cluster or the hub itself. The controller approves and signs the request, producing a valid client certificate that the hub trusts.

With the forged certificate, the attacker authenticates to the hub API as a privileged identity. From the hub, the attacker can issue work manifests to any other managed cluster, effectively achieving full cross-cluster control.

Root Cause

The root cause is improper certificate validation [CWE-295] in the OCM registration controller. The renewal handler trusts subject and group fields supplied in the incoming CSR instead of constraining them to those of the originally issued certificate. The flaw allows identity claims to be set by the requester rather than enforced by the signing authority.

Attack Vector

Exploitation requires local high-privilege access on a managed cluster. The attacker must already hold administrator rights on at least one spoke cluster. No user interaction is required, but the scope is changed because the impact crosses the trust boundary into the hub and sibling clusters. Confidentiality, integrity, and availability are all fully impacted across the multi-cluster control plane.

The vulnerability manifests in the OCM CSR approval flow. See the Arfevrier blog post on the cross-cluster escape for technical details on the exploitation path.

Detection Methods for CVE-2026-4740

Indicators of Compromise

• CSR objects on the hub cluster whose spec.username or requested subject does not match the requesting managed cluster identity.
• Approved certificates with Common Names or Organization fields referencing managed clusters other than the requester.
• Unexpected ManifestWork resources created on managed clusters that were not initiated by legitimate hub operators.
• Audit log entries showing API access to the hub kube-apiserver from client certificates immediately after CSR approval events.

Detection Strategies

• Audit all CertificateSigningRequest objects on the hub and correlate the requester identity against the requested certificate subject.
• Compare currently active client certificates issued by the OCM controller against the expected mapping of clusters to identities.
• Alert on any newly approved CSR where the requested groups include system:masters or hub-cluster identity groups.

Monitoring Recommendations

• Enable Kubernetes audit logging at the Metadata level or above for certificates.k8s.io resources on the hub cluster.
• Forward hub kube-apiserver audit logs to a centralized analytics platform for cross-cluster correlation.
• Monitor RBAC binding changes and ManifestWork creation on all managed clusters for anomalies.

How to Mitigate CVE-2026-4740

Immediate Actions Required

• Apply the Red Hat ACM security update referenced in the Red Hat CVE-2026-4740 Advisory as soon as it is available for your channel.
• Review and rotate all OCM-issued client certificates after patching to invalidate any forged credentials.
• Audit hub cluster RBAC and remove any unrecognized service accounts, roles, or bindings created during the exposure window.

Patch Information

Red Hat has published advisory information for CVE-2026-4740. Refer to the Red Hat CVE-2026-4740 Advisory and Red Hat Bugzilla Report #2450590 for fixed component versions and update procedures specific to your ACM release stream. Upstream OCM users should track the project's release notes for the corresponding patched registration controller.

Workarounds

• Restrict administrative access on managed clusters to a minimal set of trusted operators until patches are deployed.
• Disable automated CSR approval on the hub and require manual review of all OCM renewal requests during the exposure window.
• Apply network policies that limit which identities can reach the hub kube-apiserver from managed clusters.
• Enforce additional admission controllers on the hub to validate the subject and group fields of CSRs against the requester identity.

# Inspect pending and recently approved CSRs on the hub
kubectl get csr -o json | \
  jq '.items[] | {name: .metadata.name, requester: .spec.username, groups: .spec.groups, usages: .spec.usages}'

# Revoke or delete suspicious approved CSRs
kubectl delete csr <suspicious-csr-name>