Kubernetes EUVD-2026-19690

Attacker requires high-privilege access (managed cluster administrator role) on a Red Hat Advanced Cluster Management (ACM) managed cluster. No user interaction needed. Exploits improper Kubernetes client certificate validation in OCM controller to forge certificates approved for cross-cluster access, affecting hub and other managed clusters.

Real-world risk is elevated but constrained by specific prerequisites. The CVSS vector indicates local access with high privileges required (AV:L/PR:H), meaning an attacker must already compromise a managed cluster administrator account before exploiting this chain. However, the scope change (S:C) and high impact ratings (C:H/I:H/A:H) reflect the severe consequence: complete breakout from one managed cluster to potentially control the entire hub and all other managed clusters. No CISA KEV listing exists, indicating no confirmed active exploitation in the wild. A detailed technical blog post from the discovering researcher provides exploitation methodology, significantly lowering the barrier for skilled attackers in hub-spoke Kubernetes environments. The attack is automatable once initial access is achieved, and technical impact is maximal in multi-tenant cluster deployments. SSVC decision framework suggests prioritized patching for organizations running ACM/MCE in production, especially where managed clusters have varying trust levels or are operated by different administrative teams. The prerequisite of high privileges reduces immediate risk compared to unauthenticated remote exploits, but the cross-cluster escape potential makes this critical for multi-cluster architectures.

An attacker first compromises a managed cluster in a multi-tenant Kubernetes environment, gaining administrator-level access through separate vulnerabilities or credential theft. With high privileges on the managed cluster, the attacker crafts a malicious Kubernetes client certificate signing request that exploits improper validation in the OCM controller running on the hub cluster. The hub's automated certificate approval process accepts the forged certificate due to insufficient validation controls. Using the newly approved certificate, the attacker authenticates to the hub cluster with elevated privileges, breaking the isolation boundary. From the hub, the attacker pivots to other managed clusters, potentially gaining control over production workloads, stealing secrets, or deploying malicious containers across the entire multi-cluster infrastructure. Publicly available exploit methodology exists per the researcher blog post at https://blog.arfevrier.fr/open-cluster-management-cross-cluster-escape/, providing technical details that reduce exploitation complexity for sophisticated attackers.