QEMU maintainers shipped a security update on June 12, 2026 for CVE-2026-48914, a heap buffer overflow in the SCSI handling of the virtio-blk device. The bug lets a malicious virtual machine corrupt the memory of the host QEMU process and crash it, which means a denial of service for the whole hypervisor instance.
What goes wrong
The flaw sits in the virtio_blk_handle_scsi function, which processes SCSI commands coming from the guest when the virtio-blk device has SCSI passthrough enabled. The bounds check is inadequate: a malformed SCSI command descriptor block carrying an oversized data buffer triggers writes outside the intended memory bounds, corrupting the QEMU process heap.
The vulnerability does not affect the default virtio-blk configuration. It only matters when SCSI passthrough has been explicitly turned on, an option that is uncommon in standard deployments but shows up in environments that hand full SCSI semantics to their virtual machines.
Who is affected and how severe it is
The score is CVSS v4.0 8.2 (high). To trigger the bug, the attacker needs a guest with CAP_SYS_ADMIN, which usually means root or administrator privileges inside the VM itself. So it is not something an unprivileged process can fire from within the guest: the VM has to be compromised first.
The direct impact is a crash of the host QEMU process, a denial of service. In multi-tenant hosting, that crash drags down the other virtual machines sharing the same process or node, turning a local incident into a cascading outage. Although it is classed as DoS, the heap metadata corruption opens the door to chaining the bug with others and, in theory, reaching code execution on the host. No public proof of concept demonstrates that yet.
As with the vsock/virtio integer underflow (CVE-2026-23069), this kind of flaw lives at the guest-host boundary, the spot where isolation is hardest to hold. The Linux kernel and QEMU share that ground, and every poorly validated paravirtio path is a potential escape route.
How to mitigate it
The right move is to update QEMU to the fixed releases: 9.2.1, 9.1.4, 8.2.8 or later within each stable branch. If you cannot patch right away, disable SCSI passthrough on the virtio-blk device by setting scsi=off in the device parameters. That removes the affected surface entirely.
As extra measures, cut down guest capabilities and drop CAP_SYS_ADMIN where feasible, and apply seccomp filtering on Linux hosts to limit what the QEMU process can do if it gets compromised.
