Advisory · CVE-2026-93834
QEMU 9pfs use-after-free allows guest-to-host VM escape
A race condition in QEMU's 9pfs subsystem lets a malicious guest craft a fid path from stale heap data, escape the shared directory boundary, and read or write arbitrary host files or execute code as the QEMU process user.
- Vendor
- QEMU
- Product
- QEMU
- Identifier / CWE
- CVE-2026-93834
CWE-416 - Action timing
- Immediate
Explain it like I’m five
QEMU shares a folder between the guest and the host. Two workers handle requests at the same time and trip over each other, leaving a sticky note with a stale address on the shared folder. A guest that reads the note can walk out of the shared folder and into the host's own rooms.
- 01Concurrent requests
A guest user sends concurrent Tlcreate and Twalk requests to QEMU's 9pfs filesystem sharing.
- 02Race condition
A race between the main thread and a worker thread frees memory that is still referenced.
- 03Stale fid path
The attacker crafts a fid path containing stale heap data, bypassing directory traversal restrictions.
- 04Boundary escape
The guest escapes the shared directory boundary, enabling arbitrary host file read/write and code execution as the QEMU process user.
What happened
A use-after-free vulnerability in QEMU’s 9pfs (VirtFS) subsystem was disclosed on September 25, 2026. A race condition between the main thread and a worker thread when processing concurrent Tlcreate and Twalk requests allows a malicious guest user to craft a fid path containing stale heap data, bypassing directory traversal restrictions and escaping the shared directory boundary. That turns into arbitrary host file read/write and code execution as the QEMU process user: a guest-to-host VM escape. It is rated high at CVSS 8.8, with a proof of concept referenced, and Red Hat lists qemu-kvm in RHEL 8, 9, and 10 as well as OpenShift Container Platform 4 as affected.
Only guests with access to a 9pfs shared folder are in a position to exploit it, but where 9pfs is enabled the hypervisor boundary is exactly what fails.
What to do
- Inventory QEMU hosts and identify any using 9pfs/VirtFS filesystem sharing (-fsdev, -virtfs).
- Per Red Hat’s mitigation: do not configure 9pfs/VirtFS on affected instances; use virtio-fs (virtiofsd) for host-guest file sharing instead, which does not use the vulnerable code path.
- Apply vendor qemu-kvm updates as they become available for RHEL and OpenShift.
- Review guest configurations and logs for unexpected 9pfs activity, including unusual Tlcreate/Twalk traffic patterns.
- Treat any host that ran a 9pfs share with an untrusted guest as potentially compromised; inspect for unexpected processes, files, and persistence on the host.
Management note
VM escapes are rare enough to matter every time one appears. The blast radius here is bounded by 9pfs adoption, which is small, but the primitive is the complete hypervisor bypass: read and write the host, run code there. The mitigation is a configuration change, not just a patch, so it can be deployed now while updates land.