Zapscape Is KVM's Third Guest-Escape Bug This Year

The bug that keeps living in the same room

There's a pattern worth naming before the details: the most dangerous code in KVM isn't the hot path everyone stares at. It's the crufty, rarely-exercised emulation corner that only wakes up under nested virtualization. Zapscape, tracked as CVE-2026-64561, is the third guest-to-host escape this year to come out of exactly that corner — the x86 shadow MMU — and the third from the same researcher, Hyunwoo Kim.

Zapscape is a use-after-free in the recursive "zap" path that runs when KVM reclaims shadow pages. A guest with root inside its own VM can drive the host into that reclaim path, corrupt a freed shadow page, and turn the dangling reference into arbitrary code execution in the host kernel. In plain terms: rent one instance, own the box — and every other tenant on it.

What actually breaks

Shadow paging is the legacy way KVM virtualizes a guest's page tables in software. On modern CPUs the L1 guest gets hardware two-dimensional paging (EPT on Intel, NPT on AMD) and the shadow MMU mostly sits idle. It comes back to life for nested guests — an L1 hypervisor running its own L2 — where KVM has to shadow the nested page tables itself. That's the surface Zapscape lives on, and it's why nested virtualization is the load-bearing precondition for the whole thing.

KVM caps how many shadow pages a VM can hold. Allocate past the cap and the host starts reclaiming, walking a tree of shadow pages and zapping them recursively. The bug: that recursive zap doesn't properly guard on the root reference count. The proof-of-concept builds an L0→L1→L2 stack, forces L0's quota-driven reclaim, and rides the unguarded recursion into a use-after-free. The escalation trick is the elegant part — flipping the guest from long mode to PAE paging re-roles one shadow page so it's referenced as both a child page and a pinned root at once. From there the freed-but-live object becomes a write primitive into L0 kernel memory.

The public PoC targets AMD SVM/NPT. Intel isn't off the hook — it's exploitable where both EPT page-walk lengths 4 and 5 are exposed to the L1 guest. Either way, you need root inside the guest to start, which on a public cloud instance you already have by default.

Why this is the third one, not the first

Kim's Januscape (CVE-2026-53359) and the arm64 ITScape (CVE-2026-46316) landed just before this. Januscape was a 16-year-old shadow-MMU bug dormant since a 2010 commit, and notable as the first KVM escape triggerable on both Intel and AMD. ITScape was a race in arm64's vGIC-ITS interrupt emulation — a completely different subsystem, same thesis: the kernel-resident emulation KVM performs below QEMU is where you get host kernel privilege instead of a sandboxed userspace crash.

Here's the detail that should worry operators who patched fast for Januscape: Zapscape is not the same ancient code. It was introduced by a 2020 commit (f95eec9bed76) and fixed on 2026-07-21 (commit 2abd5287f083). So a host that took the early-July stable kernels carrying the Januscape fix is still exposed to this one. Different lifespan, different commit, adjacent code. Three serious escapes from one person mining one subsystem in a few months is not bad luck — it's a signal that the shadow MMU's reclaim and mode-switch paths are under-fuzzed. syzkaller doesn't naturally reach three levels deep into nested-guest reclaim. Bet on more.

Who actually has to care

Cut through the "critical, patch now" noise, because the real blast radius is narrower and weirder than the headline.

Multi-tenant clouds that expose nested virtualization. If untrusted tenants can turn on nested KVM, this is a straight guest-to-host escape and a co-tenant DoS — panic the host and every VM on that hypervisor goes down. The good news: most hyperscalers don't hand nested virt to arbitrary tenants by default. If you're on stock AWS/GCP/Azure without nested enabled, the guest can't reach the vulnerable path. The exposure is real for providers who sell nested virt as a feature, private OpenStack/Proxmox clouds, and anyone running untrusted images with nested=1.

The underrated one: local privilege escalation on single-tenant boxes. On RHEL and Fedora, /dev/kvm ships world-writable (mode 0666). Combine that with nested virtualization enabled and the affected kernel, and an unprivileged local user needs no cloud at all — they open /dev/kvm, spin up the nested stack, and escalate to host root. That quietly turns Zapscape from a cloud-provider problem into a local-root bug on a lot of developer workstations, CI runners, and lab servers.

Nested workloads in the crossfire. Kata Containers, nested-KVM CI that boots real VMs, WSL2-style setups, security sandboxes that run VMs inside VMs — these are the environments most likely to have nested virt on for legitimate reasons, and therefore most likely to be exploitable.

What to do this week

Patch is the answer: pull the vendor kernel update that references CVE-2026-64561 / commit 2abd5287f083 and reboot. RHEL, AlmaLinux, Debian and the stable trees are shipping the shadow-paging fixes as a batch — take the whole batch, since the sibling CVEs share the neighborhood.

Can't reboot the fleet today? Two mitigations buy real time, both with teeth:

• Kill nested virtualization where you don't truly need it: nested=0 on kvm_intel / kvm_amd. This closes the door entirely for the common case, at the cost of breaking legitimate nested workloads — check your CI and Kata hosts before you flip it.
• Lock down /dev/kvm on RHEL/Fedora: drop it from 0666 to 0660 and restrict to a kvm group. That kills the local-root path without touching the guest-escape path, and it breaks rootless local QEMU for anyone not in the group — a fair trade on a shared server.

The larger judgement: nested virtualization is a security boundary, and too many teams treat it as a free convenience toggle. For untrusted code it roughly doubles the kernel attack surface — you inherit the entire shadow MMU — to benefit a sliver of tenants. Off should be the default; on should be a decision you can name a reason for. The trilogy is the argument. There's likely a fourth.