Analysis of Zapscape (CVE-2026-64561)

This report details Zapscape, a critical security vulnerability identified by Hyunwoo Kim (@v4bel). Zapscape is part of the KVM Escape Trilogy, alongside ITScape (CVE-2026-46316) and Januscape (CVE-2026-53359).

📌 Executive Summary

Zapscape is a Guest-to-Host escape vulnerability affecting the KVM/x86 environment. It allows a malicious guest to break isolation and execute arbitrary commands on the host machine with kernel (root) privileges.

The flaw is a use-after-free (UAF) located within the shadow MMU emulation of KVM/x86. Specifically, the bug is triggered during the recursive zap path that occurs when shadow pages are reclaimed.

Critical Impact: This vulnerability is particularly dangerous for multi-tenant x86 public clouds that support nested virtualization, as it can be triggered solely via guest-side actions to corrupt the host kernel's shadow pages.

---

🛠 Technical Mechanism

The vulnerability resides in how KVM handles shadow page reclamation. When the system attempts to reclaim pages, a recursive "zap" process is initiated. Due to a missing root_count guard, a UAF condition is created.

Escape Flow Diagram

The Exploit Chain

The attack leverages a complex hierarchy of virtualization levels:

1. $\text{L}_0$: The physical host (or QEMU TCG) running Linux 7.1.3 with KVM_AMD.
2. $\text{L}_1$: The first-level guest. It creates long-PAE aliases to make a single shadow page act as both a child and a pinned root.
3. $\text{L}_2$: The nested guest. When $\text{L}_2$ performs VMRUN and touches memory, it triggers the $\text{L}_0$ quota reclaim.

This sequence leads to the UAF, which $\text{L}_1$ then escalates into full code execution within the $\text{L}_0$ kernel.

---

🚀 Proof of Concept (PoC)

The provided PoC is designed for AMD architectures. For safety, it is recommended to execute this within QEMU TCG.

Setup Requirements

• Download Linux kernel v7.1.3 source.
• Build the kernel using the provided kconfig.
• Create an initramfs (e.g., via BusyBox) containing the compiled PoC.

Execution Steps

To compile and run the exploit, use the following commands:

# Compile the PoC as a static binary with pthread support
gcc -O2 -g -static -pthread poc.c -o poc

# Launch the target environment via the provided QEMU script
./qemu.sh bzImage initramfs.cpio.gz

Expected Result

Upon successful exploitation, the guest escapes to the host and creates a root-owned file at /Zapscape.

Console Output:

 /$$$$$$$$ /$$$$$$ /$$$$$$$ 
|_____ $$ /$$__ $$| $$__ $$
| $$ \ $$| $$ \ $$ /$$/ 
| $$$$$$$$| $$$$$$$/ /$$/ 
| $$__ $$| $$____/ /$$/ 
| $$ | $$| $$ /$$$$$$$$
| $$ | $$| $$ |________/
|__/ |__/|__/

[+] /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

---

⚠️ Vulnerability Scope & Impact

Affected Versions

The vulnerability spans a wide range of kernel commits:

Boundary	Commit Hash	Date
Start	f95eec9bed76	2020-07-08
End	2abd5287f083	2026-07-21

Comparison: Zapscape vs. Januscape

While both target the shadow MMU, they are distinct issues.

• Similarities:
  • Both allow guest-to-host escape.
  • Both can lead to DoS (kernel panic) or RCE (root takeover).
  • Not dependent on QEMU $\rightarrow$ Both occur in the in-kernel KVM, meaning custom virtualization stacks are also at risk.
• Differences:
  • Root Cause: They have different underlying triggers within the MMU.
  • Intel Requirements: On Intel CPUs, Zapscape only triggers if both EPT page walk lengths 4 and 5 are exposed to $\text{L}_1$.

Local Privilege Escalation (LPE)

On certain distributions (like RHEL), /dev/kvm is configured with 0666 permissions (world-writable). This allows an unprivileged local user to use Zapscape as an LPE to gain root access. In this scenario, the exploit is more stable because the attacker has access to host-side VMM ioctls.

---

🛡️ Mitigation and Requirements

To successfully execute this attack in a cloud environment:

1. The attacker needs root access within the guest VM (if not available, they must chain this with another LPE, such as Dirty Frag).
2. The L1 actions must be ported to a guest kernel module.
3. The exploit must be tailored to the host's specific kconfig.

Recommendation: Organizations should implement a rigorous and sustainable patching cycle for all host hypervisors.

Conceptual representation of the isolation breach.