CVE-2025-64324: 
NixOS vulnerability analysis and mitigation

CVE-2025-64324 is a logic bug in KubeVirt's hostDisk feature that allows local attackers to read and write arbitrary files owned by more privileged users on the host system. It affects KubeVirt versions up to and including 1.5.3 and 1.6.0, with fixes available in versions 1.6.1 and 1.7.0. The vulnerability was disclosed on November 6, 2025, via a GitHub Security Advisory, and was subsequently registered in NVD on November 18, 2025. It carries a CVSS v3.1 base score of 7.7 (High) and a CVSS v4.0 base score of 8.5 (High) (GitHub Advisory, Feedly).

The root cause is a logic bug in the virt-handler component's mountHostDiskAndSetOwnership function within pkg/host-disk/host-disk.go (CWE-732: Incorrect Permission Assignment for Critical Resource; CWE-200: Exposure of Sensitive Information; CWE-123: Write-what-where Condition). When the DiskOrCreate (HostDiskExistsOrCreate) option is used, the code checks whether the target file exists: if it does not, it creates a new sparse RAW file; if it does, it skips creation. However, in both branches, the code unconditionally proceeds to call UnsafeSetFileOwnership, changing the file's owner to UID 107 (qemu) — even when the file already exists and is owned by a privileged user such as root. This allows an attacker who can define a VirtualMachine manifest with a hostDisk volume pointing to an arbitrary host path (e.g., /etc/passwd) to silently have its ownership changed to qemu, after which the VM can read and write the file directly via a block device. The HostDisk feature gate must be enabled for exploitation (GitHub Advisory, Fix PR).

Successful exploitation allows an attacker with the ability to create or modify VirtualMachine resources in a KubeVirt cluster to read and write arbitrary files on the Kubernetes host node that are owned by privileged users, including sensitive files such as /etc/passwd, SSH keys, or Kubernetes credentials. This compromises both confidentiality (unauthorized read of sensitive host data) and integrity (arbitrary write to critical system files, potentially enabling privilege escalation or persistent backdoors). Availability is not directly impacted, though corrupting critical system files could indirectly cause system instability. The attack vector is local (requiring access to the Kubernetes API to submit VM manifests), requires no user interaction, and has low complexity (GitHub Advisory).

A proof-of-concept exploit is publicly documented in the GitHub Security Advisory, demonstrating the full attack chain including reading /etc/passwd and writing arbitrary content to it from within a VM. There is no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.013% (very low probability of exploitation in the near term). The vulnerability is not listed in the CISA KEV catalog. Exploitation requires the HostDisk feature gate to be enabled in the KubeVirt deployment and the ability to create VirtualMachine resources in the cluster (GitHub Advisory, Feedly).

1. Prerequisite check: Confirm that the target KubeVirt deployment has the HostDisk feature gate enabled (check the KubeVirt CR under spec.configuration.developerConfiguration.featureGates).
2. Obtain API access: Gain access to the Kubernetes API with sufficient RBAC permissions to create VirtualMachine or VirtualMachineInstance resources in the target namespace.
3. Craft malicious VM manifest: Create a VirtualMachine manifest that includes a hostDisk volume pointing to a sensitive host file (e.g., /etc/passwd) with type: DiskOrCreate and a capacity field set (e.g., 1Gi):

volumes:
- name: host-disk
  hostDisk:
    path: /etc/passwd
    type: DiskOrCreate
    capacity: 1Gi

4. Deploy the VM: Apply the manifest (kubectl apply -f malicious-vm.yaml). The virt-handler component will process the volume, detect that /etc/passwd already exists, skip file creation, but still call UnsafeSetFileOwnership — silently changing the file's owner to UID 107 (qemu).
5. Read the target file: Once the VM is running, connect to its console (virtctl console <vm-name>) and read the block device corresponding to the host-disk volume (e.g., cat /dev/vdc) to obtain the contents of the host's /etc/passwd.
6. Write to the target file: Write arbitrary content to the block device from within the VM (e.g., echo 'attacker:x:0:0:root:/root:/bin/bash' >> /dev/vdc) to modify the host file, potentially enabling privilege escalation or persistent access (GitHub Advisory).

• Kubernetes API Logs: Audit log entries showing creation or modification of VirtualMachine or VirtualMachineInstance resources with hostDisk volumes using type: DiskOrCreate pointing to sensitive host paths (e.g., /etc/passwd, /etc/shadow, /root/.ssh/, /etc/kubernetes/).
• File System: Unexpected ownership changes on sensitive host files — files previously owned by root (UID 0) now owned by UID 107 (qemu); detectable via ls -al or file integrity monitoring tools.
• Logs: virt-handler logs showing chown/ownership operations on files not created by KubeVirt itself; entries in /var/log/ or systemd journal referencing UnsafeSetFileOwnership on unexpected paths.
• Process/Container: Presence of virt-launcher pods mounting unexpected host paths under /var/run/kubevirt-private/vmi-disks/; inspect with kubectl describe pod <virt-launcher-pod> for suspicious hostPath volume mounts.
• Network: Unexpected virtctl console sessions or API calls to VM console endpoints from unauthorized users or service accounts.

Upgrade KubeVirt to version 1.6.1 or 1.7.0 (or later), which fix the issue by restricting chown operations to only files that KubeVirt itself creates (patch commits 00d03e43 for release-1.6 and ff3b69b0 for main) (Fix PR, GitHub Advisory). As an immediate workaround for environments that cannot upgrade, disable the HostDisk feature gate in the KubeVirt CR by removing HostDisk from spec.configuration.developerConfiguration.featureGates. Additionally, restrict RBAC permissions to limit which users or service accounts can create VirtualMachine resources, and monitor for suspicious hostDisk volume definitions in VM manifests.

The vulnerability was discovered by security researchers mihailkirov, Faeris95, and jean-edouard (credited in the advisory), and was identified as part of a broader KubeVirt security audit conducted by Quarkslab on behalf of OSTIF, with results announced by the KubeVirt project and CNCF (KubeVirt Blog, CNCF Blog). Quarkslab published a technical blog post detailing the audit findings (Quarkslab Blog). The fix was discussed openly in the KubeVirt GitHub community, with maintainers debating the trade-off between security and compatibility for storage providers that do not support fsGroup.