Zapscape (CVE‑2026‑64561): In‑Depth Analysis of the Linux KVM Guest‑to‑Host Escape

Vulnerability Overview

On August 6, 2026, security researcher Hyunwoo Kim (\@v4bel) disclosed Zapscape (CVE‑2026‑64561), a high‑severity Linux kernel vulnerability that enables a guest‑to‑host escape in KVM/x86 environments. The flaw resides in the Shadow MMU management code and is classified as a Use‑After‑Free (CWE‑825) with an initial Red Hat CVSS score of 7.0.

Technical Background: KVM and Shadow MMU

Virtualization hierarchy

Physical x86 hardware
    │
    ▼
┌─────────────────────┐
│ L0: Linux host      │
│ KVM                 │
└─────────────────────┘
    │
    ▼
┌─────────────────────┐
│ L1: Guest kernel   │
│ (attacker‑controlled)│
└─────────────────────┘
    │
    ▼
┌─────────────────────┐
│ L2: Nested guest   │
└─────────────────────┘

L0 runs the KVM hypervisor, L1 is the first‑level guest, and L2 is a nested guest. To translate guest virtual addresses in nested virtualization, KVM creates software‑generated shadow page tables (struct kvm_mmu_page) that track the nested EPT/NPT mappings. link: chain into

active_mmu_pages

role

: page‑table level, direct flag, guest mode, and invalid state root_count: number of times the page is used as an MMU root parent_ptes: pointers to all parent page tables

Root Cause: Stale‑Root Check Race

The bug is a timing error: KVM first checks whether the current shadow root is stale, then ensures enough shadow‑page quota. The quota‑allocation step can free the just‑checked root, but KVM does not re‑verify the root before continuing, leading to a Use‑After‑Free.

// page‑fault entry
r = RET_PF_RETRY;
write_lock(&vcpu->kvm->mmu_lock);

// [5] check root staleness only at fault start
if (is_page_fault_stale(vcpu, fault))
    goto out_unlock;

// [6] ensure shadow‑page quota – may trigger recursive zap that invalidates the root!
r = make_mmu_pages_available(vcpu);
if (r)
    goto out_unlock;

// [7] fetch page without re‑checking root validity
r = FNAME(fetch)(vcpu, fault, &walker);

The function make_mmu_pages_available() may call kvm_mmu_zap_oldest_mmu_pages(), which can recursively free the active root without checking root_count. This creates a situation where a shadow page X is both a pinned root (root_count > 0) and a child page slated for reclamation.

Exploit Walkthrough

PoC Build and Execution

# Clone PoC repository
git clone https://github.com/V4bel/Zapscape
cd Zapscape

# Build vulnerable kernel (Linux 7.1.3) using bundled kconfig
# Compile PoC
gcc -O2 -g -static -pthread poc.c -o poc

# Prepare initramfs with BusyBox and the PoC

# Launch QEMU (requires QEMU v9.2.0+)
./qemu.sh bzImage initramfs.cpio.gz

Running poc inside the L1 guest creates the file /Zapscape on the host with owner root and mode 0644, proving successful escape.

[+] /Zapscape created by the target KVM host kernel (owner uid=0, mode=0644).
[+] exploit completed - verify with: ls -la /Zapscape
zapscape(uid=65534)$ ls -la /Zapscape
-rw-r--r-- 1 root root 0 Jul 29 05:27 /Zapscape

Weaponization Challenges in Cloud Environments

L1 kernel‑moduleization – the PoC’s L1 actions must be packaged as a kernel module.

Memory‑layout adaptation – different host kernel configurations require tuning of spray parameters.

Stability – host workloads can change memory layout dynamically.

The author states that a skilled attacker could adapt the exploit to a cloud host within a few days.

Additional Attack Surface: Local Privilege Escalation

On some distributions (e.g., RHEL‑based), /dev/kvm is world‑writable (0664), allowing unprivileged users to access the KVM interface and trigger the same exploit path for a local root gain, which is simpler and more stable than the nested‑VM route.

Affected Versions and Fixes

Linux < 5.9 – not affected (vulnerability introduced in 2020).

Linux 5.9 ~ 6.6.147 – vulnerable.

Linux 6.6.148 – fixed (commit 2abd5287f083).

Linux 6.12 ~ 6.12.100 – vulnerable; 6.12.101 – fixed.

Linux 6.18 ~ 6.18.41 – vulnerable; 6.18.42 – fixed.

Linux 7.1 ~ 7.1.5 – vulnerable; 7.1.6 – fixed.

Linux 7.2‑rc5 – fixed.

Debian releases bullseye, bookworm, trixie, and forky are affected; sid is fixed in version 7.1.6‑1.

Upstream Fix

The patch moves the stale‑root check into make_mmu_pages_available(). If quota reclamation invalidates the current root, KVM now returns RET_PF_RETRY to restart the page‑fault handling instead of continuing on an invalid root.

# Check current kernel version
uname -r

# Upgrade to a fixed kernel
sudo apt update && sudo apt upgrade linux-image-$(uname -r)

If an immediate upgrade is impossible and nested virtualization is not required, administrators can temporarily disable it:

echo "options kvm-amd nested=0" | sudo tee /etc/modprobe.d/kvm-amd.conf

Disabling nested virtualization sacrifices virtualization capabilities and is not a long‑term solution.

Detection and Monitoring Recommendations

Alert on excessive page‑fault activity or abnormal memory‑allocation patterns from a single L1 guest.

Watch for kernel MMU‑related errors inside guests.

Detect creation of unexpected files such as /Zapscape on the host.

For on‑premises KVM hosts, monitor kernel logs:

dmesg | grep -i "kvm.*mmu"
dmesg | grep -i "zap"

Conclusion

Zapscape (CVE‑2026‑64561) is a subtle race condition in KVM’s Shadow MMU that upgrades a stale‑root check failure into a full guest‑to‑host escape. The vulnerability is low‑cost to exploit for attackers with L1 kernel access, affects a wide range of recent Linux kernels, and has been patched upstream. Cloud providers should treat it as a warning that multi‑tenant isolation is not absolute and should incorporate the suggested detection measures.