CVE-2024-9779: Open Cluster Management Privilege Escalation

CVE-2024-9779 Overview

CVE-2024-9779 is a privilege escalation vulnerability in Open Cluster Management (OCM) that allows an attacker with access to worker nodes hosting the cluster-manager or klusterlet deployments to compromise the entire Kubernetes cluster. The cluster-manager deployment uses a service account bound to a ClusterRole with permission to create Pod resources. An attacker controlling a node where these pods run can steal the cluster-manager token and then mount any other service account to escalate privileges across the cluster. The vulnerability is tracked under [CWE-266: Incorrect Privilege Assignment].

Critical Impact

An attacker with control of a worker node running OCM control-plane components can steal service account tokens and gain full cluster administrative control.

Affected Products

• Open Cluster Management (OCM) cluster-manager component
• Open Cluster Management (OCM) klusterlet component
• Red Hat Advanced Cluster Management (ACM) deployments incorporating affected OCM versions

Discovery Timeline

• 2024-12-17 - CVE-2024-9779 published to NVD
• 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2024-9779

Vulnerability Analysis

The flaw arises from an overly permissive ClusterRole bound to the cluster-manager service account. This ClusterRole grants the ability to create Pod resources cluster-wide. In Kubernetes, the ability to create pods is functionally equivalent to cluster administration because a created pod can mount any service account token, including those of highly privileged accounts.

The klusterlet agent operates with comparable privileges on managed clusters. When either deployment schedules a pod onto an attacker-controlled worker node, the attacker can read the projected service account token from the node's filesystem or container runtime. Once the cluster-manager token is captured, the attacker uses it to create new pods that mount arbitrary service account tokens, including cluster-admin accounts.

Root Cause

The root cause is incorrect privilege assignment in the OCM RBAC configuration. The cluster-manager ClusterRole includes the pods/create verb without restrictive scoping or admission control to prevent privilege escalation through pod creation. Combined with the standard Kubernetes behavior of mounting service account tokens into pods, this creates a token-theft pathway from any compromised node hosting the controller.

Attack Vector

Exploitation requires the attacker to first gain control over a worker node that hosts the cluster-manager or klusterlet pod. From that node, the attacker extracts the service account token mounted into the controller pod. The attacker then authenticates to the Kubernetes API using the stolen token and issues a request to create a new pod configured to mount a high-privilege service account such as one bound to cluster-admin. The newly created pod yields a token that grants full cluster control. Technical details are documented in the Red Hat CVE-2024-9779 Advisory and the OCM GitHub Pull Request #325.

Detection Methods for CVE-2024-9779

Indicators of Compromise

• Unexpected Pod creation events in the Kubernetes audit log originating from the cluster-manager or klusterlet service account, especially pods that mount service accounts unrelated to OCM operations.
• API server authentication events using the cluster-manager service account token from source IPs or user agents that differ from the legitimate controller pod.
• New pods specifying serviceAccountName values associated with cluster-admin or other high-privilege roles in unexpected namespaces.

Detection Strategies

• Enable and centralize Kubernetes API audit logging to capture all Pod create requests and the originating service account identity.
• Compare runtime behavior of cluster-manager and klusterlet pods against baseline activity, alerting on token use from outside the controller pod network namespace.
• Deploy admission controllers such as OPA Gatekeeper or Kyverno to flag or block pod specifications referencing privileged service accounts.

Monitoring Recommendations

• Continuously monitor RBAC bindings that grant pods/create cluster-wide and alert on additions to ClusterRoles with broad pod creation scope.
• Track service account token mounts via projected volumes and correlate with the requesting pod identity using runtime visibility tools.
• Forward Kubernetes audit logs and node-level telemetry to a centralized analytics platform for cross-correlation of node compromise indicators with API server abuse.

How to Mitigate CVE-2024-9779

Immediate Actions Required

• Upgrade Open Cluster Management to the patched release referenced in GitHub Release v0.13.0 or later that incorporates the fix from Pull Request #325.
• Audit nodes that host the cluster-manager and klusterlet deployments and restrict node access to trusted administrators only.
• Rotate service account tokens and signing keys for the cluster-manager service account if node compromise is suspected.

Patch Information

The upstream fix is delivered through the Open Cluster Management project. Refer to GitHub Pull Request #325 for the code change and GitHub Release v0.13.0 for the corresponding release artifacts. Red Hat customers should follow the guidance in the Red Hat CVE-2024-9779 Advisory and the associated Red Hat Bug Report #2317916.

Workarounds

• Apply node taints and tolerations so that cluster-manager and klusterlet pods only schedule on hardened, dedicated control-plane nodes.
• Use Kubernetes admission policies to deny pods that request service accounts outside an allow-list when created by the cluster-manager identity.
• Remove or scope down the pods/create permission from the cluster-manager ClusterRole where operationally feasible, granting only the specific resources required.

# Example: restrict cluster-manager and klusterlet pods to dedicated nodes
kubectl taint nodes <control-node> ocm-control=true:NoSchedule
kubectl label nodes <control-node> node-role.kubernetes.io/ocm-control=true

# Verify current cluster-manager ClusterRole permissions
kubectl get clusterrole cluster-manager -o yaml

# Review recent pod creations performed by the cluster-manager service account
kubectl get events --all-namespaces \
  --field-selector reason=SuccessfulCreate \
  -o wide