CVE-2026-93834 is a high severity (CVSS 8.8) use-after-free in QEMU's 9pfs subsystem. A race in handling concurrent requests lets a malicious guest user escape the shared directory and read or write host files. Red Hat's mitigation is to avoid 9pfs and VirtFS sharing.
What's affected
The record does not give QEMU version numbers, and the Red Hat page I read does not either. I could not confirm a fixed version, so check Red Hat's CVE page, the upstream QEMU issue and your distribution's tracker for the build that carries the fix.
What is clear is the configuration. The flaw sits in 9pfs, the file sharing path used when a host shares a directory with a guest through the fsdev and virtfs options. Hosts that do not configure 9pfs sharing do not use the vulnerable code. The weakness is CWE-416, use after free.
Both the record and Red Hat score it 8.8. The vector is local, low complexity, low privileges, with a changed scope. In plain terms, the attacker is code inside a guest, and the impact crosses the guest boundary.
How to check if you're exposed
Look for 9p sharing on your hypervisor hosts. For plain QEMU processes:
ps aux | grep -i qemu | grep -E 'virtfs|fsdev'
For libvirt, dump each domain definition and look for filesystem entries that share a host directory.
virsh dumpxml DOMAIN | grep -i -A4 "<filesystem"
Entries that use the virtiofs driver are a different path from 9p, per Red Hat's guidance. Entries that use the default 9p style sharing are the ones to review. Then record the QEMU package version on each host and compare it with your vendor's advisory.
What to do now
- Check your vendor's advisory for a fixed QEMU build and apply it on every host that runs guests with shared folders.
- Until then, remove 9pfs or VirtFS shares from guests where you can. Red Hat suggests virtio-fs through virtiofsd for host to guest sharing, which does not use the vulnerable path.
- For guests you do not fully trust, treat any shared directory as a boundary that needs the patch before it is relied on again.
- Keep QEMU running as an unprivileged user with confinement such as SELinux or AppArmor profiles, to limit what an escape can reach.
- Restart or live migrate guests after the QEMU update, since running processes keep the old code.
Why it matters
A use after free happens when memory is freed and then used again. In this case the record says a race between the main thread and a worker thread leaves stale data in a path the code later trusts, which lets a guest step outside the directory it was given. CWE-416 bugs in code that mediates between a guest and a host are serious because the guest is the party you are trying to contain.
The record does not mark this as exploited and it is not in CISA's catalog. The upstream issue describes the reach as root inside a guest that has a shared folder, so the risk is highest for multi tenant hosts and for guests that run untrusted workloads.
Quick check
What is the quickest mitigation?
Do not configure 9pfs or VirtFS sharing on affected QEMU instances. Red Hat names virtio-fs as an alternative.
Do I need local access to the host?
No. The attacker is a user inside the guest, which the vector expresses as a local attack with a changed scope.
Sources
Last reviewed: 18 October 2026.
