Security researcher Hyunwoo Kim has disclosed Zapscape (CVE-2026-64561), a use-after-free vulnerability in the Linux kernel's KVM hypervisor that allows a privileged L1 guest to escape nested virtualization and execute arbitrary code as root on the host. The flaw resides in KVM's shadow memory management unit (MMU), the software page-table layer KVM maintains when a guest runs its own nested guest. Unlike the earlier Januscape disclosure (CVE-2026-53359), which shipped only a host-crash proof-of-concept, Zapscape's exploit runs the full chain end-to-end and drops a root-owned file on the host filesystem from inside the guest.
The vulnerability affects every KVM host running nested virtualization on x86 hardware, spanning both Intel VT-x and AMD SVM backends because the defective logic lives in shared shadow-MMU code. AMD hosts have no additional precondition for exploitation. Intel systems are only exposed when both EPT page-walk lengths 4 and 5 are visible to the L1 guest. The bug was introduced in a July 2020 commit (Linux 5.9) and was fixed upstream on July 21, 2026, in commit 2abd5287f083, which moves the stale-root check to run after quota reclaim. Red Hat rates the flaw 7.0 (Important) with a CVSS 3.1 vector of AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H; NVD has not yet published its own score.
What's New / Specs
- CVE ID: CVE-2026-64561 (Zapscape)
- Component: Linux kernel KVM x86 shadow MMU (arch/x86/kvm/mmu/mmu.c and paging_tmpl.h)
- Vulnerability type: Use-after-free (CWE-825: Expired Pointer Dereference)
- Attack vector: Local — requires root inside a guest VM with nested virtualization enabled
- Impact: Guest-to-host escape, arbitrary code execution as root on the host
- Affected kernels: Linux 5.9 through patched stable branches (6.6.148, 6.12.101, 6.18.42, 7.1.6, 7.2-rc5 and later)
- Fixed commit: 2abd5287f08319fa35764566b15c6e22cb1068db (July 21, 2026)
- Discoverer: Hyunwoo Kim (reported via Google's kvmCTF program)
The shadow MMU enforces a quota on how many shadow pages a VM may hold. When the budget is exhausted, KVM reclaims old pages. The top-level reclaim correctly skips pages still pinned as a root, but the recursive path that zaps a child after its parent disappears never applies that check. An attacker can alias one page as both a child and a pinned root; reclaim then invalidates it mid-fault while KVM continues building mappings underneath it. The freed header's list link remains attached to the active list, and the next insertion writes a kernel pointer into memory the guest can read. From there, the proof-of-concept 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.
Red Hat's advisory notes that the underlying flaw has existed since KVM first started tracking invalid roots in 2008 (commit 2e53d63acba7), but the exploitable condition only appeared in 2020 with the invariant that invalid shadow pages must never be on the active list. The fix is conceptually simple: check for a stale or invalid root after making MMU pages available, not before. Several backport commits (0026dbb7de8e, 35e77467610c, bce0d3c26e2c, f3477a6a4164) address the same issue across stable branches.
Why It Matters
Zapscape is the third entry in what Kim describes as a KVM escape trilogy, following Januscape (CVE-2026-53359) and an earlier unnamed flaw. Each iteration has expanded the practical exploit surface. Januscape's public proof-of-concept only panicked the host; the full host code-execution exploit was withheld. Zapscape ships a complete, working exploit that any tenant with root in their own VM — effectively every IaaS customer — can run to crash the physical machine, take down every co-located VM, or seize the host outright. This makes the vulnerability an urgent concern for public-cloud providers, private-cloud operators, and any organization running multi-tenant x86 infrastructure with nested virtualization enabled.
The operational risk is compounded by two factors. First, on distributions where /dev/kvm is world-writable (a default on some RHEL-family systems), the bug becomes a local privilege-escalation path that does not require guest access at all — any unprivileged local user on the host can trigger it. Second, the fix requires patching the host kernel and rebooting; until that happens, the only reliable mitigation is disabling nested virtualization via kernel parameters (kvm_amd.nested=0 or kvm_intel.nested=0), which removes the attack surface for untrusted guests but also disables a feature many CI/CD, research, and cloud workloads depend on. Enabling CONFIG_LIST_HARDENED blocks the post-free write and downgrades the escape to a crash, though Ubuntu currently ships with this setting disabled.
Cloud Security Alliance research on Januscape highlighted that the fix for that flaw required two coupled kernel commits rather than one, and administrators who patched against a single CVE identifier may have believed they were protected when they were not. Zapscape's fix appears to be a single commit, but the pattern underscores the need for thorough patch management across all related CVEs in the shadow-MMU subsystem. Organizations should treat deployment of the patched kernels (6.6.148, 6.12.101, 6.18.42, 7.1.6, or 7.2-rc5 and later) as an urgent priority alongside a review of nested virtualization exposure and /dev/kvm permissions.
Our Take
Zapscape demonstrates how a subtle invariant violation in shared hypervisor code can become a full guest-to-host escape with a relatively short exploit chain. The fact that the bug survived for six years (2020-2026) in a code path exercised by every nested-virtualization workload on both major x86 vendors is a reminder that hypervisor attack surfaces age poorly when they sit at the boundary of guest-controlled input and host-privileged execution. The exploit's reliance on slab-cache crossing and KASLR leakage via the PM notifier chain shows modern kernel exploitation technique, but the root cause — a missing stale-root check after quota reclaim — is a straightforward logic error that could have been caught by more rigorous invariant testing.
For defenders, the immediate actions are clear: apply the patched kernel, disable nested virtualization if a reboot cannot be scheduled immediately, and restrict /dev/kvm to the kvm group. Longer term, the recurrence of shadow-MMU use-after-free bugs (Januscape, Zapscape, and the companion CVE-2026-46113) suggests this subsystem warrants dedicated fuzzing and formal verification investment. The kvmCTF program that surfaced Zapscape is a model worth expanding; Google's $250,000 reward for a full guest-to-host escape aligns incentives correctly and has now produced two major disclosures in short order. Until the patched kernels are widely deployed, any environment that grants untrusted tenants root in a VM with nested virt enabled should be considered at high risk of host compromise.
FAQ
What is the difference between Zapscape and Januscape?
Januscape (CVE-2026-53359) was a use-after-free in the same shadow-MMU code where KVM reused shadow pages based on guest frame number alone, ignoring the page's role. Its public proof-of-concept only crashed the host; the full exploit was withheld. Zapscape (CVE-2026-64561) is a distinct use-after-free in the recursive reclaim path that fails to check for pinned roots before zapping child pages. Crucially, Zapscape's proof-of-concept executes the full chain and drops a root-owned file on the host, demonstrating practical code execution.
Which systems are vulnerable to Zapscape?
Any Linux host running KVM with nested virtualization enabled on x86 hardware (Intel VT-x or AMD SVM) and using a kernel between 5.9 and the patched stable releases (6.6.148, 6.12.101, 6.18.42, 7.1.6, 7.2-rc5 or later). AMD hosts have no additional precondition. Intel hosts are only exploitable when both EPT page-walk lengths 4 and 5 are visible to the L1 guest. Systems without nested virtualization enabled are not exposed.
Can Zapscape be exploited without a guest VM?
Yes, on distributions where /dev/kvm is world-writable (notably some RHEL-family defaults), any unprivileged local user on the host can trigger the vulnerability directly, turning it into a local privilege-escalation path that does not require guest access. Locking down /dev/kvm permissions to the kvm group mitigates this vector.
What mitigations are available if I cannot reboot the host immediately?
Disable nested virtualization by setting kvm_amd.nested=0 or kvm_intel.nested=0 on the kernel command line and rebooting (or loading the module with the parameter). This removes the attack surface for untrusted guests. Enabling CONFIG_LIST_HARDENED at kernel compile time blocks the post-free write and downgrades the escape to a crash, though this requires a custom kernel build on most distributions (Ubuntu currently ships it disabled).
How does the upstream fix address the vulnerability?
Commit 2abd5287f083 moves the check for a stale or invalid root to run after making MMU pages available during quota reclaim. Previously, the check ran before reclaim, allowing a race where a pinned root could be zapped mid-fault while KVM continued building mappings under it. The fix ensures that if reclaim invalidates an in-use root, KVM will not attempt to map memory into that invalid root, preserving the invariant that invalid shadow pages are never on the active list.
