CVE-2025-64436 Overview
CVE-2025-64436 affects KubeVirt, a virtual machine management add-on for Kubernetes. The vulnerability exists in versions 1.5.0 and earlier. Excessive permissions granted to the virt-handler service account allow an attacker who compromises a node to abuse Virtual Machine Instance (VMI) update and node patch rights. An attacker can force VMI migration to an attacker-controlled node or mark all nodes as unschedulable. This condition can force the migration or creation of privileged pods onto a compromised node, expanding attacker control within the cluster. The weakness is categorized as improper privilege management [CWE-269].
Critical Impact
Abuse of virt-handler permissions enables cluster-wide manipulation of VMI scheduling and forced placement of privileged workloads onto compromised nodes.
Affected Products
- KubeVirt 1.5.0 and earlier
- KubeVirt deployments on Kubernetes clusters
- Virtualized workloads managed through the virt-handler DaemonSet
Discovery Timeline
- 2025-11-07 - CVE-2025-64436 published to NVD
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2025-64436
Vulnerability Analysis
KubeVirt runs a per-node agent called virt-handler that manages VMI lifecycle operations on each Kubernetes node. The service account bound to virt-handler receives permissions to update VMI objects and patch node resources. These rights are broader than required for node-local operations. An attacker who gains code execution on any single node inherits the virt-handler service account token on that node. The attacker can then invoke the Kubernetes API using those credentials against the entire cluster. This design flaw enables cross-node influence from a single compromised host.
Root Cause
The root cause is over-privileged Role-Based Access Control (RBAC) bindings assigned to the virt-handler service account. Update and patch verbs on VMI and Node resources are granted cluster-wide rather than scoped to the local node. The permission model does not enforce the boundary that a node-local agent should only mutate objects tied to its own node.
Attack Vector
An attacker first compromises a node running the virt-handler pod or obtains its service account token. Using the token, the attacker patches Node objects to set unschedulable: true across the cluster. The attacker then updates target VMI specifications to force live migration onto a node they control. When privileged pods or VMIs land on the attacker-controlled node, the attacker gains access to sensitive workloads, secrets, and VM memory. The vulnerability requires prior access to a node context but does not require user interaction to escalate impact cluster-wide.
No public proof-of-concept exploit is available. See the KubeVirt GitHub Security Advisory GHSA-7xgm-5prm-v5gc for maintainer-provided technical details.
Detection Methods for CVE-2025-64436
Indicators of Compromise
- Kubernetes audit log entries showing the virt-handler service account patching Node objects it does not run on.
- VMI spec.nodeSelector or migration target changes originating from the virt-handler service account outside of expected reconciliation flows.
- Multiple nodes transitioning to SchedulingDisabled state within a short time window.
- Unexpected live-migration events for VMIs hosting privileged or sensitive workloads.
Detection Strategies
- Enable Kubernetes API server audit logging at the Metadata level or higher for nodes and virtualmachineinstances resources.
- Alert on any patch or update verb executed by system:serviceaccount:kubevirt:kubevirt-handler targeting a node other than the one hosting the calling pod.
- Correlate VMI migration events with the identity that initiated the change and flag operations not originating from virt-controller.
Monitoring Recommendations
- Baseline normal virt-handler API activity per node and alert on deviations.
- Monitor for bulk unschedulable transitions across the node inventory.
- Track service account token usage from unexpected source IPs or pods within the cluster network.
How to Mitigate CVE-2025-64436
Immediate Actions Required
- Upgrade KubeVirt to a fixed release above 1.5.0 as published in the KubeVirt GitHub Security Advisory.
- Audit existing RBAC bindings for the virt-handler service account and remove any custom over-permissive roles.
- Review recent Kubernetes audit logs for unauthorized node patch or VMI update operations.
- Rotate the virt-handler service account token if compromise is suspected.
Patch Information
The KubeVirt maintainers addressed the issue by tightening the RBAC permissions granted to virt-handler so that update and patch operations are scoped to the node hosting the agent. Consult the official advisory GHSA-7xgm-5prm-v5gc for the exact fixed version and upgrade instructions.
Workarounds
- Restrict node access using Pod Security Admission and hardened container runtimes to reduce the chance of node compromise.
- Apply Kubernetes admission policies (Kyverno or OPA Gatekeeper) that reject Node patches from the virt-handler service account targeting nodes other than the local one.
- Isolate KubeVirt workloads from general-purpose workloads using dedicated node pools to limit blast radius.
# Example Kyverno policy restricting virt-handler node patching
# Apply only after validating against your cluster configuration
kubectl apply -f - <<EOF
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: restrict-virt-handler-node-patch
spec:
validationFailureAction: Enforce
rules:
- name: block-cross-node-patch
match:
any:
- resources:
kinds:
- Node
operations:
- UPDATE
- PATCH
exclude:
any:
- subjects:
- kind: ServiceAccount
name: kubevirt-controller
namespace: kubevirt
validate:
message: "virt-handler may only patch its own node"
deny:
conditions:
any:
- key: "{{ request.userInfo.username }}"
operator: Equals
value: "system:serviceaccount:kubevirt:kubevirt-handler"
EOF
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
