libvirt CVE-2026-63623

Exploitation requires a local user account on the KVM/libvirt hypervisor host (CVSS PR:L confirmed). The vulnerability is triggered only when a libvirt storage volume clone or convert operation is actively in progress - the world-readable file exists only during the transient window between qemu-img creating the file and libvirt correcting its permissions. An attacker must be able to monitor the libvirt storage directory and read files during this window, which requires filesystem-level visibility into the storage path. Guest OS users cannot exploit this vulnerability directly - they must have local shell access on the hypervisor host itself. Exploitation is further constrained by the need to time the read during an active clone/convert operation, making passive opportunistic exploitation less reliable than targeted attacks against predictable operational workflows. Non-default but not unusual conditions: shared development KVM hosts, CI/CD virtualization nodes, or any environment where non-admin users have local shell access alongside hypervisor operations.

The CVSS 3.1 score of 5.5 (Medium) with vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N accurately reflects the threat model: local low-privileged access is required, but once obtained, the attacker can read the full contents of guest disk images with low complexity. The high confidentiality impact (C:H) is the dominant risk signal here. The absence of a KEV listing and no identified POC lower immediate urgency for most organizations, but in multi-tenant or shared KVM environments - such as development servers, CI/CD pipelines, or cloud infrastructure nodes - where multiple users of differing trust levels share a hypervisor host, this vulnerability represents a concrete and meaningful threat. EPSS data was not provided in source intelligence, so probabilistic exploitation likelihood cannot be quantified. The exploitation window is transient (only while a clone/convert operation is in progress), which introduces a timing dependency that marginally limits opportunistic exploitation but does not prevent a motivated local attacker from polling the filesystem. No integrity or availability impact is present.

A low-privileged local user on a shared KVM host writes a script that continuously polls the libvirt storage directory (e.g., /var/lib/libvirt/images/) using inotifywait or a tight readdir loop. When an administrator or automated system initiates a storage volume clone or convert operation, the newly created image file appears briefly as world-readable; the attacker's script immediately opens and reads the file, extracting raw disk contents including credentials, private keys, or sensitive application data from the guest virtual machine. No public POC has been identified at time of analysis.