CVE-2025-64435 Overview
CVE-2025-64435 is a logic flaw in the KubeVirt virt-controller that allows an attacker with limited Kubernetes privileges to disrupt control over a running Virtual Machine Instance (VMI). By creating a pod with the same labels as the legitimate virt-launcher pod associated with a VMI, an attacker can mislead the controller into associating the fake pod with the VMI. This causes incorrect status updates and can result in denial-of-service against the affected VMI. The vulnerability affects KubeVirt versions prior to 1.7.0-beta.0 and is tracked under [CWE-703] (Improper Check or Handling of Exceptional Conditions).
Critical Impact
An authenticated Kubernetes user able to create pods in a VMI's namespace can hijack controller reconciliation logic and induce denial-of-service on running virtual machines.
Affected Products
- KubeVirt versions prior to 1.7.0-beta.0
- KubeVirt 1.7.0-alpha0
- KubeVirt add-on deployments on Kubernetes clusters
Discovery Timeline
- 2025-11-07 - CVE-2025-64435 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2025-64435
Vulnerability Analysis
KubeVirt extends Kubernetes with custom controllers that reconcile VirtualMachineInstance (VMI) resources against underlying virt-launcher pods. The virt-controller component tracks each VMI's pod by matching Kubernetes labels. The flaw lies in how the controller identifies the pod belonging to a VMI: it relies on label matching rather than authoritative ownership metadata.
An attacker who can create pods in the same namespace can craft a pod carrying the same labels as the legitimate virt-launcher. The controller then treats the attacker's pod as authoritative for that VMI. Subsequent reconciliation propagates incorrect phase and status information back to the VMI object, disrupting orchestration and producing a denial-of-service condition against the running workload.
Root Cause
The root cause is the use of label-only selection inside the controller's pod-lookup path. The pre-patch helper IsControlledBy in pkg/controller/controller_ref.go did not enforce a strict owner-reference check. Because Kubernetes labels are non-unique and mutable by any user with pod-create permissions, this design allowed impersonation of the controller-managed virt-launcher pod.
Attack Vector
Exploitation requires network access to the Kubernetes API and low-privilege credentials with pod-create rights in the target namespace. The attack complexity is high because the attacker must time pod creation and label crafting to align with the target VMI's reconciliation cycle. No user interaction is required, and the impact is limited to availability of the affected VMI.
// Security patch in pkg/controller/controller.go
// The fix replaces custom label-based ownership checks
// with the upstream metav1.IsControlledBy owner-reference check.
var curPod *k8sv1.Pod = nil
for _, pod := range pods {
- if !IsControlledBy(pod, vmi) {
+ if !metav1.IsControlledBy(pod, vmi) {
continue
}
Source: KubeVirt commit 9a6f4a3a
Detection Methods for CVE-2025-64435
Indicators of Compromise
- Pods in VMI namespaces carrying virt-launcher labels but lacking a valid ownerReferences entry pointing to a legitimate VMI resource.
- Unexpected VMI status transitions (Failed, Unknown, or Scheduling) that do not correlate with node-level virt-handler events.
- Duplicate pods sharing the same VMI label set (kubevirt.io=virt-launcher, kubevirt.io/created-by=<uid>) in a single namespace.
Detection Strategies
- Audit Kubernetes API server logs for CREATE pod requests where labels match virt-launcher patterns but the requesting ServiceAccount is not the KubeVirt controller.
- Compare pod ownerReferences.uid against the target VMI UID during reconciliation drift investigations.
- Alert on VMI phase oscillation in short time windows, which indicates conflicting status writes from mismatched pods.
Monitoring Recommendations
- Enable Kubernetes audit logging at RequestResponse level for pod and VMI resources across KubeVirt namespaces.
- Stream cluster audit events and KubeVirt controller logs into a centralized analytics pipeline for correlation of pod-creation events with VMI status changes.
- Track RBAC bindings that grant pods/create in namespaces hosting production VMIs and review them regularly.
How to Mitigate CVE-2025-64435
Immediate Actions Required
- Upgrade KubeVirt to 1.7.0-beta.0 or later, which introduces owner-reference validation via metav1.IsControlledBy.
- Restrict pods/create permissions in namespaces where VMIs run to trusted service accounts only.
- Review existing pods in VMI namespaces for anomalous labels matching the virt-launcher schema.
Patch Information
The fix is included in KubeVirt 1.7.0-beta.0. The commit 9a6f4a3a removes the custom controller_ref.go helper and replaces label-based association with Kubernetes' standard metav1.IsControlledBy owner-reference check. See the GitHub Security Advisory GHSA-9m94-w2vq-hcf9 for full remediation guidance.
Workarounds
- Apply Kubernetes RBAC policies that deny pod creation with kubevirt.io reserved labels from non-system accounts.
- Deploy an admission controller (OPA Gatekeeper or Kyverno) to reject user-created pods that carry virt-launcher labels or spoof KubeVirt owner references.
- Isolate VMI workloads into dedicated namespaces with strict NetworkPolicy and RBAC boundaries until the patch is applied.
# Example Kyverno policy: block user-created pods using virt-launcher labels
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: block-virt-launcher-label-spoofing
spec:
validationFailureAction: Enforce
rules:
- name: deny-virt-launcher-label
match:
any:
- resources:
kinds:
- Pod
exclude:
any:
- subjects:
- kind: ServiceAccount
name: kubevirt-controller
namespace: kubevirt
validate:
message: "Pods with kubevirt.io=virt-launcher labels may only be created by the KubeVirt controller."
pattern:
metadata:
=(labels):
X(kubevirt.io): "!virt-launcher"
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
