A newly disclosed vulnerability in KubeVirt lets an attacker with control over a PersistentVolumeClaim read files from the virt-launcher pod—and possibly the underlying node—by slipping symlinks into a virtual machine's disk mounts. The fix is available in releases 1.5.3 and 1.6.1, and every administrator running Windows or Linux VMs on Kubernetes should apply it immediately.

KubeVirt, the extension that brings full virtual machines into Kubernetes clusters, pairs each VM with a helper pod called virt-launcher. This pod uses libvirt to present disks, often backed by PVCs, to the guest. CVE-2025-64433 arises because libvirt’s disk-attachment logic trusts the contents of a PVC without sufficiently validating whether a file is a symlink pointing outside the intended storage boundary.

An attacker who can write to a PVC—either directly or through a self-service provisioner—can place a symbolic link inside it that targets a sensitive file on the virt-launcher pod’s filesystem, such as /etc/passwd, service-account tokens, or VM configuration data. When libvirt attaches that PVC as a disk, it follows the symlink and presents the target file to the guest as a readable block device. A secondary bug then incorrectly changes the ownership of the target file to the unprivileged runtime user (UID 107), bypassing normal access checks.

The result: a virtual machine can read data it should never see, breaking the isolation between the container and the guest. The attack does not grant code execution, but exfiltrated credentials or configuration can easily be chained into wider compromise. Microsoft, which maintains the CVE listing in its Security Response Center, rates the vulnerability as moderately severe with a CVSS 3.1 base score of 6.5.

Who’s Affected and How Serious It Is

Every KubeVirt deployment running a version earlier than 1.5.3 or any 1.6.x release before 1.6.1 is vulnerable. If you are using KubeVirt on Windows Server nodes—supported since KubeVirt 1.0 with Windows 11 and Server 2022 guests—the same flaw applies. The risk is highest in multi-tenant clusters where untrusted users can provision or write to PVCs.

For single-tenant enterprise clusters with strictly operator-controlled storage, the practical exploitability drops significantly. But if your CI/CD pipelines, developer namespaces, or external contractors have any ability to create or modify PVCs, you should treat this as a high-priority patch. A typical attack scenario looks like this:

  • A DevOps engineer creates a PVC for a build agent.
  • An adversary compromises a low-privilege account in the same namespace and alters the PVC contents to include a symlink.
  • The next time the VM boots or the disk is hot-plugged, the symlink resolves to a file containing cloud credentials, the virt-launcher’s kubeconfig, or other sensitive data.
  • The guest VM reads the file, and the data is exfiltrated.

The flaw is fundamentally a confidentiality breach—it leaks data across a supposedly solid boundary. It does not directly corrupt memory or execute code on the host, but the information gained can enable those next steps. Microsoft’s advisory underscores the importance of patching even when public proof-of-concept code is not yet widely observed.

What It Means for You

For IT administrators running KubeVirt on Windows or Linux:

  • Every cluster that mounts PVCs into VMs must be inspected. If any tenant or user other than a strict set of administrators can create or write to PVCs, the vulnerability is exploitable today with a simple ln -s command.
  • Patching alone eliminates the root cause, but you should also audit PVC write permissions. Use Kubernetes RBAC to restrict create and update actions on PersistentVolumeClaims. In multi-tenant environments, consider enforcing immutable volumes or rejecting PVCs that contain symlinks via an admission controller.
  • Windows nodes are not immune. The vulnerability lives in the KubeVirt control plane and virt-launcher, not in the guest OS. A Windows VM can just as easily read a leaked file as a Linux VM can.

For developers and DevOps engineers using KubeVirt to run Windows VMs:

  • If your pipelines or test harnesses dynamically provision PVCs, review who can modify those volumes after creation. A compromised CI token could turn a routine build into a data leak.
  • Treat PVCs with the same supply-chain scrutiny as container images. Scan them for symlinks and unexpected files before they get mounted by a VM.

For security teams:

  • Add KubeVirt components to your vulnerability scan cadence. The virt-launcher image is a critical piece of your cluster’s security perimeter.
  • Enable Kubernetes audit logging and watch for PVC write events from unexpected identities, especially just before a VM starts or a disk is hot-attached.

How We Got Here

KubeVirt first appeared in 2017 and has since become a standard way to run VMs alongside containers. The design is elegant: each VM runs inside a pod, and virt-launcher handles the translation between Kubernetes volumes and the virtual hardware the guest sees. That tight integration with PVCs is what makes snapshotting, migration, and dynamic provisioning possible.

But this design also blurs the line between cloud-native storage and traditional virtualization. PVCs are essentially blob storage that Kubernetes pods can mount; they were never designed to carry filesystem tricks like symlinks that cross mount boundaries. Libvirt, on the other hand, comes from a world where disk images are local files, and it has long accepted regular files as block devices. The collision of these two assumptions created the gap that CVE-2025-64433 exploits.

Similar cross-layer issues have surfaced before. In 2022, a flaw in Kubernetes mount propagation allowed a privileged container to access node filesystems. Here, the path is reversed: a VM reaches out through a symlink to read a pod’s files. The common thread is that storage abstraction layers can hide dangerous paths unless the entire chain—from provisioner to hypervisor—is hardened.

Microsoft has been steadily expanding its support for KubeVirt, especially for hybrid Windows-Linux clusters. Windows Server 2022 and Windows 11 guests are first-class citizens in KubeVirt 1.0 and later. That means a growing number of Windows-focused shops now operate exactly the kind of environment where this vulnerability bites.

What to Do Now

1. Patch immediately.
Upgrade to KubeVirt 1.5.3 or 1.6.1 without delay. The release artifacts are available from the KubeVirt GitHub repository. Verify that the virt-launcher image digest matches the patched version after rolling out the update.

2. Harden PVC access.
Run an RBAC audit to list every identity that can create or update PVCs. Tighten the permissions so that only clearly trusted service accounts—not every developer’s personal account—can write to volumes that will feed VMs. In a pinch, block all PVC creation by non-admin users until you can patch.

3. Scan existing PVCs for symlinks.
Execute a one-time scan of all PVCs in namespaces that run KubeVirt workloads. A simple job that mounts each PVC and checks for lstat-detected symlinks can reveal whether an exploit has already been planted.

4. Add an admission gate.
Deploy an Open Policy Agent (OPA) or Kyverno policy that rejects PVCs containing symlinks if they are destined for a VM. This provides a second layer of defense even if an attacker slips past RBAC.

5. Turn on audit logging and alerts.
Enable Kubernetes API audit logging at the RequestResponse level for PVC resources. Feed the logs to your SIEM and create alerts for create or update operations from principals that do not normally touch storage.

6. Validate the fix.
After patching, perform a controlled test: create a PVC with a symlink pointing to a harmless file inside a test pod, attach it to a VM, and verify that the symlinked file is either rejected or rendered unreadable.

Outlook

The CVE-2025-64433 patch closes a specific symlink-based path, but the broader class of storage-to-VM boundary issues will likely draw more scrutiny. As KubeVirt matures and more enterprises run mixed Windows-Linux workloads on it, we can expect a wave of security research into the interactions between Kubernetes volumes, libvirt, and QEMU. Administrators should watch for additional hardening patches in upcoming KubeVirt releases and consider contributing to the project’s security working group.

In the short term, treat PVCs with the same suspicion you’d apply to any externally supplied input. A volume is not just a bag of bits; its filesystem structure can carry invisible threats. The days of assuming a VM is perfectly isolated from its pod are over—especially when that pod shares a namespace with other tenants.