CVE-2025-64436
📋 TL;DR
This vulnerability in KubeVirt allows attackers with access to the virt-handler service account to force VM migrations to compromised nodes or mark all nodes as unschedulable. This affects KubeVirt deployments up to version 1.5.0 running in Kubernetes environments. Attackers could potentially migrate privileged workloads to nodes they control.
💻 Affected Systems
- KubeVirt
📦 What is this software?
Kubevirt by Kubevirt
Kubevirt by Kubevirt
⚠️ Risk & Real-World Impact
Worst Case
Attacker gains control of privileged pods or VM workloads by forcing migration to compromised nodes, potentially leading to data exfiltration, lateral movement, or cluster disruption.
Likely Case
Attacker with existing cluster access abuses permissions to disrupt workload scheduling or migrate specific workloads to controlled nodes for further exploitation.
If Mitigated
Limited impact due to proper RBAC controls, network segmentation, and monitoring preventing unauthorized access to virt-handler service account.
🎯 Exploit Status
Requires access to the virt-handler service account credentials or token. Exploitation involves Kubernetes API calls to update VMI objects or patch node status.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: 1.5.1 and later
Vendor Advisory: https://github.com/kubevirt/kubevirt/security/advisories/GHSA-7xgm-5prm-v5gc
Restart Required: Yes
Instructions:
1. Update KubeVirt to version 1.5.1 or later. 2. Apply the updated manifests. 3. Restart KubeVirt components. 4. Verify the virt-handler service account permissions have been reduced.
🔧 Temporary Workarounds
Restrict virt-handler RBAC permissions
linuxManually reduce the permissions granted to the virt-handler service account to minimum required for operation.
kubectl edit clusterrole virt-handler
kubectl edit clusterrolebinding virt-handler
🧯 If You Can't Patch
- Implement strict network policies to limit virt-handler service account access to only necessary Kubernetes API endpoints.
- Enable audit logging for virt-handler service account activities and monitor for suspicious VMI updates or node patching.
🔍 How to Verify
Check if Vulnerable:
Check KubeVirt version: kubectl get deployment -n kubevirt kubevirt-operator -o jsonpath='{.spec.template.spec.containers[0].image}'. If version is 1.5.0 or earlier, you are vulnerable.Check Version:
kubectl get deployment -n kubevirt kubevirt-operator -o jsonpath='{.spec.template.spec.containers[0].image}'Verify Fix Applied:
Verify KubeVirt version is 1.5.1 or later and check virt-handler service account permissions: kubectl describe clusterrole virt-handler.📡 Detection & Monitoring
Log Indicators:
- Unauthorized VMI update requests from virt-handler service account
- Suspicious node patching activities marking nodes as unschedulable
- Unexpected VM migration events
Network Indicators:
- Unusual Kubernetes API calls from virt-handler service account to update/patch endpoints
SIEM Query:
source="kubernetes-audit" AND user.username="system:serviceaccount:kubevirt:virt-handler" AND (verb="update" OR verb="patch") AND objectRef.resource="virtualmachineinstances"