Security researcher Hyunwoo Kim closed out his KVM escape trilogy today with Zapscape (CVE-2026-64561), and this time he shipped the whole thing.
Where the earlier Januscape disclosure went public with a proof-of-concept that only panicked the host, the full host code-execution exploit stayed unreleased. Zapscape's PoC runs the chain end-to-end and drops a root-owned /Zapscape file on the host filesystem from inside a guest VM.
That difference matters for anyone running multi-tenant x86 infrastructure. A tenant with root in their own VM — which is to say, every IaaS customer — can crash the physical machine and take every co-located VM down with it, or take the host over outright.
Zapscape is a use-after-free in KVM's shadow MMU (the software page tables KVM maintains when a guest runs its own nested guest). KVM caps how many shadow pages a VM may hold, and reclaims old ones when the budget runs dry.
The top-level reclaim skips pages still pinned as a root, but the recursive path that zaps a child after its parent disappears never applies that check. Alias one page as both a child and a pinned root, and reclaim invalidates it mid-fault while KVM keeps building mappings underneath it. The freed header's list link stays attached to the active list, and the next insertion writes a kernel pointer into memory that the guest can read.
From there, the PoC crosses two slab caches into guest memory, leaks the KASLR slide through the PM notifier chain, then chains log_wait, an SRCU workqueue, and the user-mode helper path to execute /bin/sh with kernel credentials.
AMD hosts have no additional precondition. Intel systems are only exposed when both EPT page-walk lengths 4 and 5 are visible to L1.
The bug dates to a July 2020 commit and was fixed upstream on July 21 in 2abd5287f083, which simply moves the stale-root check to run after quota reclaim.
What to do now: patch the host kernel. If you can't reboot yet, kvm_amd.nested=0 or kvm_intel.nested=0 removes the attack surface for untrusted guests. Lock down /dev/kvm on RHEL-family systems, where world-writable permissions turn this into a local root exploit. And check your kconfig — enabling CONFIG_LIST_HARDENED blocks the post-free write and downgrades the escape to a crash, a setting Ubuntu currently ships disabled.