CVE-2024-9779 in Open Cluster Management
Summary
by MITRE • 12/18/2024
A flaw was found in Open Cluster Management (OCM) when a user has access to the worker nodes which contain the cluster-manager or klusterlet deployments. The cluster-manager deployment uses a service account with the same name "cluster-manager" which is bound to a ClusterRole also named "cluster-manager", which includes the permission to create Pod resources. If this deployment runs a pod on an attacker-controlled node, the attacker can obtain the cluster-manager's token and steal any service account token by creating and mounting the target service account to control the whole cluster.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 02/26/2026
The vulnerability described in CVE-2024-9779 represents a critical privilege escalation flaw within the Open Cluster Management framework that directly undermines cluster security boundaries. This issue specifically affects environments where attackers have compromised access to worker nodes hosting critical OCM components. The flaw exploits a fundamental design weakness in the cluster-manager deployment's security model, where the service account named "cluster-manager" possesses excessive permissions that extend beyond what is typically required for normal operation. This misconfiguration creates a direct path for attackers to escalate their privileges from node-level access to full cluster control through a well-defined attack vector.
The technical implementation of this vulnerability stems from the improper binding of ClusterRole permissions to the cluster-manager service account, which includes the critical ability to create Pod resources. When an attacker successfully compromises a worker node where the cluster-manager or klusterlet deployments are running, they can leverage this elevated permission to create malicious pods that mount the cluster-manager's service account token. This creates a direct attack path that maps to CWE-269: "Improper Privilege Management" and CWE-787: "Out-of-bounds Write" in the context of privilege escalation. The attack leverages the principle of least privilege violation, where the service account has permissions that exceed its operational requirements.
From an operational impact perspective, this vulnerability enables complete cluster compromise through what appears to be a relatively simple attack pattern. The attacker can obtain the cluster-manager's token and subsequently access any service account token within the cluster, effectively providing them with administrative capabilities across all workloads and resources managed by the Open Cluster Management system. This represents a severe escalation from node compromise to cluster-wide administrative access, allowing attackers to exfiltrate data, deploy malicious workloads, modify cluster configurations, and potentially move laterally to other clusters in interconnected management environments. The impact aligns with ATT&CK technique T1078.004: "Valid Accounts: Cloud Accounts" and T1566.002: "Phishing: Spearphishing Attachment" when considering how attackers might initially gain node access.
The mitigation strategies for this vulnerability must address both the immediate security gap and the underlying architectural issues. Organizations should immediately implement strict pod security policies that prevent the creation of pods with excessive permissions, particularly those that can mount service account tokens from other components. The recommended approach includes implementing Pod Security Admission controls with restricted policies, ensuring that service accounts have minimal required permissions, and implementing proper network segmentation between nodes hosting different cluster components. Additionally, the cluster-manager service account should be restricted to only necessary permissions, and the deployment should be configured to avoid running on attacker-controlled nodes through proper node labeling and taints. This aligns with security best practices from the Kubernetes Security Guidelines and the CIS Kubernetes Benchmark, specifically addressing controls related to service account management and privilege escalation prevention. The vulnerability also highlights the importance of implementing proper RBAC policies and regular security audits of cluster components to prevent similar issues in other deployments.