Zapscape flaw in Linux KVM lets a rogue guest break out to the host
A newly disclosed bug in the Linux kernel's virtualization layer, tracked as CVE-2026-64561, could let an attacker inside a nested virtual machine reach the physical server underneath.
Key points
- Researchers disclosed a Linux kernel flaw nicknamed Zapscape, tracked as CVE-2026-64561, affecting KVM's shadow memory management on x86.
- The bug lets an attacker with kernel privileges inside a first-level guest virtual machine escape isolation and run code on the host.
- Exposure is limited to systems that turn on nested virtualization for untrusted guests, a setup common at cloud and hosting providers.
- No public reports of exploitation in the wild have surfaced so far, and no known threat cluster has been tied to the research.
- Administrators should watch the mainline kernel and their distribution vendors for the patch and disable nested virtualization where it is not needed.
A new Linux kernel flaw called Zapscape could let an attacker who already controls a virtual machine break out and take over the physical computer running it. That is the kind of boundary a cloud provider spends a lot of money keeping intact.
The bug was first reported by The Hacker News and is tracked as CVE-2026-64561. It sits inside KVM, the piece of the Linux kernel that lets one server host many virtual machines at once.
What is actually broken?
The flaw is in KVM's shadow memory management unit, or shadow MMU, the component that keeps track of how each guest's memory maps to the real memory on the host. When nested virtualization is switched on, meaning a virtual machine is allowed to run its own virtual machines inside itself, that mapping gets more complicated. Zapscape abuses a mistake in how those shadow pages are cleaned up.
In plain terms: a guest can trick the host into mishandling memory the guest was never supposed to touch. From there, an attacker with kernel-level access inside the first-level guest, known as L1, can run their own code on the host machine underneath.
Who is actually at risk?
Only systems that expose nested virtualization to guests they do not fully trust. That is a narrow but important set: public cloud tenants running their own hypervisors, hosting providers offering nested setups, and some research or testing environments.
A laptop running a single virtual machine for testing is not the target here. A shared server letting customers spin up their own virtualized workloads is.
| Item | Detail |
|---|---|
| CVE ID | CVE-2026-64561 |
| Nickname | Zapscape |
| Component | KVM/x86 shadow MMU |
| Precondition | Nested virtualization exposed to untrusted L1 guest |
| Impact | Guest-to-host code execution |
How serious is a guest-to-host escape?
Very. The whole point of a hypervisor is that whatever happens inside a virtual machine stays inside it. When that wall cracks, one tenant on a shared server can reach the host and, in theory, every other tenant sharing it.
That said, capability is not the same as intent. No public exploitation has been reported, and no named intrusion set, whether a criminal ransomware crew or a state-linked group, has been tied to this research. Treat the risk as real but not yet weaponized.
What should administrators do now?
Watch for the kernel patch landing in mainline Linux and in your distribution's security channel, then apply it on hypervisor hosts first. Where nested virtualization is not needed, turn it off; it is a feature many operators leave enabled by default without using it.
Cloud customers do not need to do anything on their own guests to fix this. The fix has to happen on the host, which means waiting for your provider to patch and reboot, or to live-migrate workloads onto patched hardware.
One caveat worth stating clearly. Details on Zapscape are still thin at the time of writing, and the practical difficulty of exploitation is not yet public. Assessments here are medium confidence and will firm up as vendor advisories land.
