CVE-2025-64435
📋 TL;DR
This vulnerability in KubeVirt allows attackers to disrupt virtual machine control by creating malicious pods with matching labels. Attackers can cause denial-of-service by misleading the virt-controller into associating fake pods with legitimate VMIs. This affects all KubeVirt deployments prior to version 1.7.0-beta.0.
💻 Affected Systems
- KubeVirt
📦 What is this software?
Kubevirt by Kubevirt
Kubevirt by Kubevirt
⚠️ Risk & Real-World Impact
Worst Case
Complete loss of control over running virtual machines, inability to manage VM lifecycle, and persistent DoS affecting multiple VMs in the cluster.
Likely Case
Temporary disruption of specific VM operations, incorrect status reporting, and potential service interruptions for affected workloads.
If Mitigated
Limited impact with proper RBAC controls and network policies preventing unauthorized pod creation in critical namespaces.
🎯 Exploit Status
Requires understanding of KubeVirt architecture and pod labeling; attacker needs sufficient Kubernetes permissions to create pods.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: 1.7.0-beta.0 and later
Vendor Advisory: https://github.com/kubevirt/kubevirt/security/advisories/GHSA-9m94-w2vq-hcf9
Restart Required: Yes
Instructions:
1. Backup your KubeVirt configuration. 2. Update KubeVirt to version 1.7.0-beta.0 or later using: kubectl apply -f https://github.com/kubevirt/kubevirt/releases/download/v1.7.0-beta.0/kubevirt-operator.yaml. 3. Wait for all components to restart. 4. Verify the virt-controller pods are running the new version.
🔧 Temporary Workarounds
Restrict Pod Creation Permissions
linuxImplement strict RBAC controls to limit who can create pods in namespaces containing KubeVirt VMIs.
kubectl create role restricted-pod-creator --verb=create --resource=pods --namespace=kubevirt
kubectl create rolebinding restrict-pods --role=restricted-pod-creator --user=trusted-user --namespace=kubevirt
Network Policy Isolation
linuxApply network policies to isolate virt-launcher pods from unauthorized pod communication.
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: isolate-virt-pods
namespace: kubevirt
spec:
podSelector:
matchLabels:
kubevirt.io: virt-launcher
policyTypes:
- Ingress
- Egress
ingress:
- from:
- podSelector:
matchLabels:
kubevirt.io: virt-controller
EOF
🧯 If You Can't Patch
- Implement strict RBAC controls to limit pod creation permissions in KubeVirt namespaces to only trusted users/service accounts.
- Monitor for unauthorized pod creation events in KubeVirt namespaces using Kubernetes audit logging and alerting.
🔍 How to Verify
Check if Vulnerable:
Check KubeVirt version: kubectl get deployment -n kubevirt virt-controller -o jsonpath='{.spec.template.spec.containers[0].image}'. If version is earlier than 1.7.0-beta.0, you are vulnerable.Check Version:
kubectl get deployment -n kubevirt virt-controller -o jsonpath='{.spec.template.spec.containers[0].image}'Verify Fix Applied:
Verify virt-controller is running version 1.7.0-beta.0 or later: kubectl get pods -n kubevirt -l kubevirt.io=virt-controller -o jsonpath='{.items[*].spec.containers[*].image}'. Test by attempting to create a pod with virt-launcher labels - it should not affect VM status.📡 Detection & Monitoring
Log Indicators:
- Unauthorized pod creation events in kubevirt namespace
- Multiple pods with same labels as virt-launcher pods
- VMI status updates from unexpected pod sources
Network Indicators:
- Unusual network traffic between newly created pods and virt-controller
SIEM Query:
event.dataset: kubernetes.audit AND kubernetes.object.type: pods AND kubernetes.object.namespace: kubevirt AND event.action: create AND NOT user.name: system:serviceaccount:kubevirt:*