CVE-2026-63623

CVE-2026-63623 rates as CVSS 5.5, but the number obscures a design failure that matters more than the score suggests. When libvirt invokes qemu-img for clone or convert operations, it passes a file path and lets qemu-img's default umask determine permissions. The result is a window where guest disk images — the highest-sensitivity artifacts in any virtualization environment — become world-readable. The severity isn't adequately captured by the temporal qualifier. A one-second window to extract a complete VM's memory state from disk is not meaningfully lower severity than persistent exposure. World-readable guest images mean any local process during that window can read what amounts to the entirety of a guest's memory and storage. In multi-tenant environments where storage pools are shared across VMs, this exposure potentially extends to every guest on the host — not just the one being cloned. The deeper problem is architectural: this isn't an isolated misconfiguration, it's a repeated pattern in Linux security hygiene. The same failure mode appeared in cron environments, container runtimes, and systemd units — each community solved it in isolation without building a durable taxonomy that hypervisor toolchains could inherit. Libvirt inherited the debt without knowing it existed. For remediation, two paths exist with different blast-radius implications. Fixing it in libvirt's subprocess invocation hygiene solves this instance but creates a maintenance burden future developers will route around. Fixing qemu-img's default umask protects all qemu-img consumers, not just libvirt — a wider protective radius. The durable fix requires making secure subprocess handling the path of least resistance, likely through a library or wrapper that bakes umask, capability, and seccomp requirements into fork-exec calls. Practitioners should treat the libvirt-to-qemu-img interface as an unmaintained security boundary. Verify your storage pools use SELinux labels or mandatory access controls that govern the creation moment itself, not just post-creation permissions. Audit other qemu-img invocations in your tooling — if this delegation pattern exists here, it likely exists elsewhere in your stack.

Reviewed through automated stages and approved by a human before publication.