CVE-2025-64433: Kubevirt Path Traversal Vulnerability

CVE-2025-64433 Overview

CVE-2025-64433 is a path traversal vulnerability in KubeVirt, a virtual machine management add-on for Kubernetes. The flaw allows a guest VM to read arbitrary files from the virt-launcher pod's file system through improper symlink handling during Persistent Volume Claim (PVC) disk mounting. An attacker with control over PVC contents can create a symbolic link pointing to sensitive files. Because libvirt treats regular files as block devices, the linked target is mounted into the VM and becomes readable. A secondary flaw changes file ownership to unprivileged UID 107 before mounting, defeating the intended containment boundary. The vulnerability is tracked as [CWE-22] and affects KubeVirt versions prior to 1.5.3 and 1.6.1.

Critical Impact
A tenant controlling PVC contents can read arbitrary files from the virt-launcher pod, exposing secrets, service tokens, and mounted volumes.

Affected Products

KubeVirt versions prior to 1.5.3
KubeVirt 1.6.0 (including alpha0, beta0, rc0, rc1) prior to 1.6.1
Kubernetes clusters running KubeVirt with tenant-controlled PVCs

Discovery Timeline

2025-11-07 - CVE-2025-64433 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-64433

Vulnerability Analysis

KubeVirt runs each virtual machine inside a virt-launcher pod that hosts the libvirt and QEMU processes. When a VM references a PVC-backed disk, KubeVirt resolves the disk image path inside the pod and passes it to libvirt for attachment. The disk-preparation code in pkg/host-disk/host-disk.go did not verify that the resolved path stayed within the intended volume directory. A tenant who could write to the PVC prior to mount could place a symbolic link named like the expected disk image but pointing elsewhere in the pod file system.

The process compounds a second flaw. To align permissions with the unprivileged runtime user, KubeVirt changes the ownership of the disk file to UID 107 before mounting. When the target is a symlink, the chown follows the link and rewrites ownership on the linked file. This defeats the UID 107 sandbox and grants the guest VM read access to any file reachable in the pod namespace.

Root Cause

The root cause is unsafe path resolution combined with symlink-following file operations, categorized as [CWE-22] Path Traversal. The hostdisk package did not use symlink-safe syscalls when opening or chown-ing disk targets, allowing the mount routine to leave the volume boundary.

Attack Vector

The attack requires network-adjacent access with low privileges — specifically, the ability to place content into a PVC that will be attached to a VM. The attacker writes a symlink into the PVC pointing at a target such as a service account token or configuration file, then boots the VM and reads the file through the guest's block device.

// Patch excerpt from pkg/host-disk/host-disk.go
 package hostdisk
 
 import (
+	"errors"
 	"fmt"
 	"os"
 	"path"
 	"path/filepath"
 	"syscall"
 
+	"golang.org/x/sys/unix"
 	"kubevirt.io/client-go/log"
 
 	ephemeraldiskutils "kubevirt.io/kubevirt/pkg/ephemeral-disk-utils"
// Source: https://github.com/kubevirt/kubevirt/commit/09eafa068ec01eca0e96ebafeeb9522a878dbf64

The fix adds the golang.org/x/sys/unix package to use symlink-safe operations (such as openat2 with RESOLVE_NO_SYMLINKS) so disk preparation stays contained inside the intended volume directory.

Detection Methods for CVE-2025-64433

Indicators of Compromise

Unexpected symbolic links inside PVC volumes that point outside the volume root or toward paths such as /var/run/secrets, /proc, or /etc.
virt-launcher pod logs showing disk attachment of files not matching expected disk image extensions or sizes.
Ownership changes (chown to UID 107) applied to files outside /var/run/kubevirt-private on the pod file system.

Detection Strategies

Audit PVC contents for symlinks before VM start using an admission controller or pre-mount hook.
Monitor Kubernetes audit logs for VM creation events tied to PVCs recently written by tenant workloads.
Correlate libvirt domain XML block device paths with the resolved on-disk target to identify mounts that traverse symlinks.

Monitoring Recommendations

Alert on file access patterns inside virt-launcher pods where guest I/O reads paths outside /var/run/kubevirt-private/vmi-disks.
Track KubeVirt version inventory across clusters and flag any node still running versions below 1.5.3 or 1.6.1.
Enable Kubernetes runtime security tooling to detect symlink creation targeting sensitive paths within tenant-writable PVCs.

How to Mitigate CVE-2025-64433

Immediate Actions Required

Upgrade KubeVirt to version 1.5.3 or 1.6.1, which contain the symlink-safe disk preparation logic.
Inventory all PVCs attached to VMs and inspect them for symlinks placed by tenants prior to the upgrade.
Rotate any Kubernetes service account tokens or secrets that were reachable inside virt-launcher pods on affected clusters.

Patch Information

The vendor fix is delivered in KubeVirt 1.5.3 and 1.6.1. The patch adds symlink-safe file operations to the hostdisk package and contains disk resolution inside the volume directory. See the KubeVirt Security Advisory GHSA-qw6q-3pgr-5cwq and the fix commits 09eafa06, 9dc798cb, and a81b27d4.

Workarounds

Restrict which tenants can create or write to PVCs that will be attached as VM disks using Kubernetes RBAC and namespace isolation.
Use pre-provisioned, read-only golden disk images rather than tenant-writable PVCs where feasible.
Deploy an admission webhook that rejects VMs whose backing PVCs contain symbolic links.

bash

# Verify installed KubeVirt version and upgrade if below 1.5.3 / 1.6.1
kubectl get kubevirt -n kubevirt -o jsonpath='{.items[*].status.observedKubeVirtVersion}'

# Apply the fixed release
export RELEASE=v1.6.1
kubectl apply -f https://github.com/kubevirt/kubevirt/releases/download/${RELEASE}/kubevirt-operator.yaml
kubectl apply -f https://github.com/kubevirt/kubevirt/releases/download/${RELEASE}/kubevirt-cr.yaml

# Confirm rollout
kubectl -n kubevirt wait kv kubevirt --for=condition=Available --timeout=10m