Zapscape: Hyunwoo Kim's Third KVM Escape Raises Systemic…

CVE-2026-64561 is a use-after-free in the KVM/x86 shadow MMU discovered by Hyunwoo Kim. It allows a kernel-privileged L1 guest to break isolation and execute code on the host.

On August 6, 2026, Hyunwoo Kim disclosed CVE-2026-64561, a use-after-free vulnerability in the KVM/x86 shadow MMU that lets kernel-privileged code in an L1 guest escape isolation and execute instructions on the Linux host. It is the third escape in the researcher's "trilogy" in just two months, following ITScape and Januscape, all rooted in the same kernel area. The significance extends beyond a single bug: it reveals a systemic class of vulnerabilities in a component considered among the most critical for cloud service security.

Key Takeaways

CVE-2026-64561 is a use-after-free in the KVM/x86 shadow MMU, discovered by Hyunwoo Kim: a kernel-privileged L1 guest can execute code on the host.
The bug has existed since 2020 (Linux 5.9, commit f95eec9bed76) and was fixed on July 21, 2026 with commit 2abd5287f083; fixed versions are 6.6.148, 6.12.101, 6.18.42, 7.1.6, and 7.2-rc5.
On Intel it requires both EPT page-walk lengths 4 and 5 exposed to L1; on AMD no equivalent conditions exist and the attack surface is wider.
Red Hat assigns CVSS 3.1 7.0 (AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H) and classifies CWE-825; RHEL 8, 9, and 10 are affected, RHEL 6 and 7 are not.

How the Race Condition in the Shadow MMU Works

The mechanism targets KVM's shadow page management, the address translation system that emulates the MMU for virtualized guests. When an L1 guest generates a page fault, the host kernel traverses a handling path that includes reclaiming MMU pages to free space. The problem, according to the researcher's documentation, lies in the order of operations: the stale root check occurs before make_mmu_pages_available(), but the reclaim can invalidate that root in an unprotected time window.

The fault path proceeds with an already-invalidated root, creates child pages that inherit role.invalid from the parent, and inserts them into the active MMU pages list. This violates the fundamental invariant that pages marked invalid must never reside on that list. The result is a classic use-after-free: dangling pointers to already-freed structures, with the possibility of post-free writes. The PoC published by Kim creates a /Zapscape file owned by root on the host, demonstrating code execution outside the guest context.

"Zapscape is a stale-root check ordering flaw in KVM's shadow-MMU bookkeeping that can lead to a use-after-free"

The Timeline of a Discovery Spanning the Full Disclosure Cycle

The report to security@kernel.org is dated July 11, 2026. The patch was merged ten days later, on July 21. A coordinated embargo with linux-distros followed, expiring on August 1, CVE assignment on August 4, and public disclosure on August 6. This timeline shows a functioning coordination process, but also structural latency: the bug persisted across six years of kernels before identification, and nearly a month elapsed between report and public disclosure.

The temporal persistence is significant. The commit-to-commit range spans from July 9, 2020 to July 21, 2026. In those six years, every Linux system with kernel 5.9 or later that exposed nested virtualization to untrusted guests carried this vulnerability. Fixed versions were released as 6.6.148, 6.12.101, 6.18.42, 7.1.6, and 7.2-rc5, according to verified sources.

Why Zapscape Is the Third Act of a Larger Story

The context that makes this advisory relevant goes beyond the single CVE. ITScape and Januscape, Kim's two previous escapes, share the same attack surface: the KVM/x86 shadow MMU. This recurrence suggests the problem is not an isolated error, but a systemic bug class in a complex, under-audited subsystem. The shadow MMU manages implicit states and race conditions on structures shared between host and guest: natural territory for use-after-free and logic flaws.

The practical impact centers on multi-tenant cloud providers offering nested virtualization. In these environments, a tenant with kernel privileges in an L1 VM can theoretically compromise the host hypervisor, breaking the fundamental isolation on which the entire public cloud security model rests. Kim explicitly stated he has no evidence of in-the-wild exploitation, but the public PoC lowers the barrier for targeted attacks.

An Intel-specific scope condition is worth noting: the vulnerability requires both EPT page-walk lengths 4 and 5 to be exposed to L1. On AMD, according to sources, this limitation does not exist. This architectural asymmetry means AMD environments with nested SVM/NPT present a wider attack surface, without additional configuration requirements.

Immediate Actions

For administrators running infrastructure with KVM and nested virtualization, the priority is verifying the kernel version on host nodes. Kernels prior to the fixed versions 6.6.148, 6.12.101, 6.18.42, 7.1.6, and 7.2-rc5 are vulnerable and require patching.

For multi-tenant cloud providers, the assessment must focus on the actual need to expose nested virtualization to untrusted tenants. Sources do not specify alternative mitigations beyond the kernel patch: the absence of documented workarounds makes updating the only verifiable countermeasure.

For RHEL operators, Red Hat confirms impact on RHEL 8, 9, and 10 with CVSS 3.1 7.0, while RHEL 6 and 7 do not contain the vulnerable code. The score reflects attack complexity (AC:H) but also complete impact on confidentiality, integrity, and availability.

Kim's PoC is not a weaponized exploit for real cloud environments, but demonstration code requiring adaptation. This does not diminish the severity: publication of the full mechanism accelerates the potential development of operational variants.

The Challenge of Sustainable Hypervisor Patching

Kim closed his repository with a direct recommendation: establish a sustainable patching process for host hypervisors. The statement, with its explicit quote, signals an underlying awareness: hypervisors are often considered "secure by design" thanks to virtualization, but this perception breeds operational complacency. A hypervisor's host kernel is no less sensitive than any other critical system, yet it is updated less frequently due to fear of downtime and regressions.

The shadow MMU "trilogy" is a case study in how this complacency translates into persistent vulnerabilities. If a single researcher identified three escape bugs in two months in the same area, the remaining audit surface is likely extensive. The question cloud providers must ask is not whether a fourth escape will arrive, but when and whether their update processes will be fast enough to catch it.

The dossier does not specify how many providers actually expose nested virtualization to untrusted tenants, nor does it provide estimates of vulnerable systems in production. These limits leave part of the mass risk assessment unresolved, but they do not reduce the criticality for exposed infrastructures.

Information verified against cited sources and current as of publication.

Sources

Sources and references