CVE-2024-10220

What it actually does

The kubelet allows arbitrary command execution through specially crafted gitRepo volumes that abuse volume mounting to run attacker-controlled commands during pod initialization.

Why it matters to the business

Successful exploitation grants attackers control over Kubernetes worker nodes, enabling data theft, workload disruption, or lateral movement across clusters; urgency is moderate given low EPSS and lack of KEV listing despite broad ecosystem prevalence of affected kubelet versions.

How an attack unfolds

An attacker with permission to create pods supplies a malicious gitRepo volume definition that points to a repository containing commands executed by the kubelet during volume setup, achieving remote code execution without needing elevated privileges beyond pod creation rights.

How to fix it

Upgrade kubelet to versions 1.28.12 or later, 1.29.7 or later, or 1.30.3 or later; until upgrades are complete, restrict pod creation privileges and avoid use of gitRepo volumes in untrusted namespaces.

How to confirm the fix worked

Verify kubelet versions across nodes match or exceed the fixed releases; test by attempting to schedule a pod with a gitRepo volume on patched nodes and confirm no command execution occurs.

Typical attack path

1. Obtain permissions to submit pod specifications to the cluster
2. Craft a pod manifest containing a gitRepo volume with a malicious repository URL or branch that triggers command execution
3. Submit the pod to a node running an affected kubelet version
4. Kubelet processes the volume and executes the embedded commands on the host
5. Attacker uses resulting shell access to pivot or persist within the cluster

How to detect it

Review Kubernetes audit logs for pod creations that include gitRepo volumes from unexpected repositories; inspect node process execution logs for git or shell activity triggered by volume mounts shortly after pod scheduling.

What your security team should do

• Prioritize patching all nodes to fixed kubelet versions within standard change windows given the RCE nature
• Audit RBAC policies to limit pod creation to trusted service accounts
• Monitor for unusual gitRepo volume usage in pod specs via admission controllers or audit logs
• Disable gitRepo volumes cluster-wide if the feature is not required