Description

A flaw was found in libvirt. During storage volume clone or convert operations, newly created volume images were temporarily world-readable. This was caused by the `qemu-img` utility running with overly permissive file creation settings, allowing any local user to read the full guest disk contents. This vulnerability could lead to sensitive information disclosure from guest virtual machines.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.5",
  "pubDate": "2026-08-10T17:17:35.413Z",
  "pubdate": "2026-08-10T17:17:35.413Z",
  "executiveSummary": "A vulnerability has been identified in libvirt concerning storage volume clone and convert operations, resulting in sensitive information disclosure. The flaw stems from the `qemu-img` utility executing with overly permissive file creation settings during these specific storage management routines. Consequently, newly instantiated volume images are temporarily rendered world-readable on the host system filesystem. This exposure allows unauthorized local users to read the full contents of the guest virtual machines, potentially compromising sensitive data stored within the disk images. The vulnerability impacts systems utilizing libvirt for storage volume lifecycle management. The risk implication involves local privilege escalation concerning data confidentiality, as malicious actors with local access to the host can intercept confidential guest assets during the brief window of insecure file instantiation. Exploitation requires local system access and precise timing or monitoring capabilities to access the unprivileged temporary files before permissions are subsequently corrected by the host system.",
  "technicalDetails": "The vulnerability resides within the libvirt storage driver component responsible for executing storage volume clone and convert routines. Specifically, the root cause is tied to the invocation parameters and execution context of the `qemu-img` utility. During the creation of destination volume images via cloning or format conversion, `qemu-img` initializes the target files utilizing default, overly permissive process umask or explicit file creation modes that fail to restrict access appropriately at the moment of creation. As a result, the newly generated disk image files inherit world-readable permissions upon initial instantiation on the host filesystem.\nThe attack flow proceeds as follows: First, a privileged user, automated management plane, or API initiates a storage volume clone or conversion operation via libvirt. Second, libvirt invokes the external `qemu-img` binary to perform the heavy-lifting data transfer and format translation. Third, `qemu-img` creates the destination file on the shared or local storage pool without enforcing strict restrictive POSIX file permissions (such as 0600). Fourth, during the race window between file creation and subsequent permission hardening steps applied by libvirt, any authenticated local user with read access to the directory path can open and read the file descriptor of the nascent image.\nThe affected components comprise the libvirt storage volume management subsystem and the interaction layer with the `qemu-img` utility. Authentication and privilege requirements for exploitation dictate that the attacker must possess local system access (shell or execution privileges) on the hypervisor host. Network exposure is non-existent as the vector is strictly local to the underlying host operating system filesystem. Post-exploitation impact centers on unauthorized information disclosure; because the target file contains a full guest disk image, the attacker gains access to plaintext configuration files, cryptographic keys, database contents, and other sensitive artifacts residing within the guest virtual machine."
}