Zapscape flaw in Linux KVM lets a rogue guest break out to the host

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 disable nested virtualization where it is not needed and watch distribution vendors for the patch.

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's the kind of boundary a cloud provider spends serious money keeping intact.

The bug is tracked as CVE-2026-64561, first reported by The Hacker News. It sits inside KVM, the piece of the Linux kernel that lets one server host many virtual machines at once. Zapscape isn't the first KVM escape we've tracked this summer: our 16 July coverage of Januscape showed a flaw that had sat in shared Intel and AMD code for over a decade.

What is actually broken?

The flaw lives in KVM's shadow memory management unit (shadow MMU), the component that maps each guest's memory to real host memory. Switch on nested virtualization, meaning you allow a virtual machine to run its own virtual machines inside itself, and that mapping grows far more complicated. Zapscape abuses a mistake in how those shadow pages are cleaned up.

A guest can trick the host into mishandling memory it was never supposed to touch. An attacker with kernel-level access inside the first-level guest, known as L1, can then run arbitrary code on the host machine itself.

Who is actually at risk?

Only systems that expose nested virtualization to guests they don't fully trust. Public cloud tenants running their own hypervisors, hosting providers offering nested setups, research environments: those are the targets. A laptop running a single test VM is not.

How serious is a guest-to-host escape?

Very. The hypervisor's entire value is containment. When that wall cracks, one tenant on a shared server can reach the host and, in theory, every other tenant on it.

Capability isn't intent, though. No public exploitation has been reported. No named intrusion set, criminal or state-linked, has been tied to this research. Real risk, not yet weaponized.

What should administrators do now?

Watch for the kernel patch in mainline Linux and in your distribution's security channel, then apply it on hypervisor hosts first. Where nested virtualization isn't needed, turn it off; many operators leave it enabled by default without actually using it.

Cloud customers don't need to act on their own guests. The fix has to happen on the host, which means waiting for your provider to patch and reboot, or live-migrating workloads onto patched hardware.

Details on Zapscape are still thin. The practical difficulty of exploitation isn't yet public. Treat assessments here as medium confidence; they'll firm up as vendor advisories land.

Common questions

Does this affect AMD as well as Intel processors?

SOURCE specifies KVM/x86 and shadow MMU; it doesn't break out per-vendor CPU exposure. Watch vendor advisories for that detail.

Should cloud customers demand confirmation their provider has patched?

Yes. Ask your provider for a patching timeline. If nested virtualization is a feature you're paying for, you need to know when the underlying host is fixed.