CVE-2026-64561, publicly named Zapscape, is a Linux KVM/x86 vulnerability that turns a subtle shadow-MMU state-management failure into something much more serious: under the right nested-virtualization conditions, code controlled by a privileged guest can cross the KVM isolation boundary and reach the host kernel.
That distinction matters because the official Linux vulnerability description initially sounds narrower than the demonstrated security impact. The kernel.org CVE record describes a stale-root validation problem in which KVM can continue mapping memory after shadow-page reclamation has invalidated the MMU root being used by the current page-fault path. Child shadow pages can then inherit that invalid state while still being placed on KVM’s list of active MMU pages. (NVD)
Security researcher Hyunwoo Kim, who discovered and reported Zapscape, demonstrated where that broken invariant can lead. His public research develops the inconsistent shadow-page state into a use-after-free condition and a post-free write, then demonstrates a complete guest-to-host escape against an AMD nested-KVM setup. The published proof of concept ultimately causes the target host kernel to create /Zapscape, owned by root. (GitHub)
Zapscape therefore deserves to be assessed as more than a kernel crash bug.
It is also important not to overstate it. CVE-2026-64561 is not an unauthenticated network RCE against every Linux server, nor does an ordinary process inside every KVM guest automatically gain the ability to escape. The demonstrated attack depends on nested virtualization and L1 guest kernel privilege, and Intel systems have an additional EPT capability requirement that does not apply to the demonstrated AMD path. (GitHub)
As of August 7, 2026, a public PoC exists, but the researcher describes it as demonstration code rather than a cloud-ready weaponized exploit. Public reporting does not claim that CVE-2026-64561 has been observed in real-world attacks. (GitHub)
CVE-2026-64561 Zapscape at a Glance
| פריט | Current information |
|---|---|
| CVE | CVE-2026-64561 |
| Public name | Zapscape |
| רכיב | Linux kernel KVM/x86 shadow MMU |
| סוג הפגיעות | Expired pointer / use-after-free exploitation path |
| Security boundary | KVM guest-to-host isolation |
| Primary prerequisite | Nested virtualization exposed to an attacker-controlled L1 guest |
| Guest privilege | L1 kernel privilege required for the demonstrated guest escape |
| AMD | Public full-chain PoC demonstrated using nested SVM/NPT |
| Intel | Nested VMX/EPT plus both EPT page-walk lengths 4 and 5 must be exposed to L1 for the documented alias |
| Demonstrated impact | Host kernel/root code execution |
| Other impact | Host denial of service; possible local privilege escalation in suitable /dev/kvm configurations |
| Upstream affected baseline | Linux 5.9 onward until the relevant stable fix |
| Upstream fixed stable branches recorded by kernel.org | 6.6.148, 6.12.101, 6.18.42, 7.1.6, 7.2-rc5 |
| Mainline fix | 2abd5287f083 |
| Public PoC | כן |
| Known in-the-wild exploitation | No public claim identified as of August 7, 2026 |
| Red Hat CVSS | Preliminary CVSS 3.1 score 7.0 |
| NVD CVSS | Not yet scored by NVD at the time reviewed |
The version information above comes directly from the kernel.org CNA data included by NVD. Red Hat currently assigns a preliminary 7.0 score with local attack vector, high attack complexity, low privileges, no user interaction, and high confidentiality, integrity, and availability impacts. (NVD)
That score should not be read in isolation. In a cloud or hosting environment that deliberately grants untrusted tenants nested virtualization, the security boundary being crossed is potentially the physical host boundary itself.
What Is Zapscape?
Zapscape is a vulnerability in the shadow memory management unit used by KVM on x86.
KVM must translate memory differently depending on the virtualization topology. In a normal single-level configuration, an L0 host runs an L1 VM. Hardware-assisted mechanisms such as Intel Extended Page Tables, or EPT, and AMD Nested Page Tables, or NPT, allow much of the guest-to-host address translation to be performed efficiently in hardware.
Nested virtualization adds another level:
Physical x86 hardware
|
v
+-----------------------------+
| L0 Linux host |
| KVM |
+-----------------------------+
|
v
+-----------------------------+
| L1 guest / guest hypervisor |
| attacker-controlled |
+-----------------------------+
|
v
+-----------------------------+
| L2 nested guest |
+-----------------------------+
The Linux kernel documentation defines exactly this terminology: L0 is the bare-metal KVM host, L1 is the guest hypervisor, and L2 is the nested guest running underneath L1. (Linux Kernel Documentation)
The translation problem becomes more complicated at this point.
L1 can construct EPT or NPT mappings for its L2 guest, but the real machine is still managed by L0. A single hardware translation stage cannot independently represent every layer of this nested relationship. KVM consequently maintains software-generated shadow pages representing the nested translation state.
Zapscape attacks the lifecycle and bookkeeping of those shadow pages.
Kim’s technical analysis explains that nested EPT/NPT shadowing reaches KVM’s legacy shadow-MMU infrastructure on both Intel and AMD, even when the host can use a different MMU strategy for ordinary VM memory. (GitHub)
That makes the bug a KVM issue rather than a QEMU device-emulation bug.
CVE-2026-64561 Is Not a QEMU Vulnerability
This distinction is operationally important.
The public Zapscape demonstration uses QEMU as part of its laboratory environment, but the vulnerable component is in-kernel KVM. Kim explicitly states that the vulnerability occurs independently of QEMU’s device emulation. (GitHub)
Replacing QEMU with a different userspace virtual-machine monitor therefore does not, by itself, remove CVE-2026-64561 if the underlying virtualization stack still exposes the vulnerable KVM behavior.
This also explains why the vulnerability deserves attention beyond conventional Linux desktop virtualization. A cloud provider can build a substantial proprietary control plane and userspace virtualization stack while still relying on KVM for hardware virtualization. The relevant question is not simply “Does this infrastructure run QEMU?” but rather:
Does an affected KVM/x86 kernel expose the necessary nested virtualization functionality to an untrusted guest?
That is the correct exposure boundary.
The Root Cause: KVM Checks the Root, Then Changes the World
At the center of CVE-2026-64561 is an ordering problem.
During vulnerable KVM page-fault handling, the shadow-MMU path effectively performs operations in this order:
write_lock(&vcpu->kvm->mmu_lock);
if (is_page_fault_stale(vcpu, fault))
goto out_unlock;
r = make_mmu_pages_available(vcpu);
if (r)
goto out_unlock;
r = FNAME(fetch)(vcpu, fault, &walker);
The important question is what can happen between the first and third operations.
is_page_fault_stale() verifies whether the root associated with the current fault is still valid.
Then make_mmu_pages_available() רצות.
That function may need to reclaim shadow-MMU pages when KVM approaches its per-VM shadow-page quota. Reclamation can therefore zap existing shadow pages.
The problem is that this reclaim operation can invalidate the same root that was just checked.
The subsequent fetch then continues as if the previous stale-root decision were still valid.
The official kernel CVE description summarizes the failure precisely: if shadow-page reclamation zaps an in-use root and marks it invalid, KVM can still attempt to map memory into that invalid root. (NVD)
The problem resembles a time-of-check/time-of-use failure, although its mechanics are specific to KVM MMU object lifetime rather than a conventional filesystem TOCTOU race.
Conceptually:
1. Check root
|
| root is valid
v
2. Reclaim MMU pages
|
| recursive zap invalidates root
v
3. Continue fault handling
|
| code assumes previously checked state
v
4. Create mappings beneath invalid root
The critical invariant has changed between the validation and the operation that depends upon it.
Why an Invalid Root Becomes More Than a Logic Error
Merely using an invalid root does not automatically produce host kernel code execution.
Zapscape becomes exploitable because another piece of KVM behavior compounds the error.
When KVM creates a child shadow page, the child’s role is derived from the parent. In the vulnerable sequence, the parent has already been marked invalid.
The child’s role therefore inherits the parent’s invalid state.
Kim shows the relevant behavior in kvm_mmu_child_role(): the parent role is copied before selected fields are changed, without clearing the inherited invalid bit. (GitHub)
The new shadow page is nevertheless inserted into active_mmu_pages.
This creates an impossible state according to KVM’s normal MMU invariants:
Shadow page C
role.invalid = 1
+
member of active_mmu_pages
The official kernel record explicitly calls out this contradiction, noting that invalid shadow pages must not exist on the active MMU page list. (NVD)
The exploitability comes from what later cleanup code assumes about those invariants.
Recursive Zap Is the Critical Transition
The name Zapscape is closely tied to KVM’s “zap” terminology.
A shadow page is “zapped” when KVM invalidates and tears down the corresponding shadow-MMU state.
Normal quota reclamation avoids directly reclaiming an active root that still has a non-zero root_count.
However, Kim found that another path exists while recursively removing nested mappings. Under the required object relationship, a shadow page can simultaneously participate as a child and remain pinned as an MMU root.
The recursive cleanup path checks that its parent relationship has disappeared, but the vulnerable behavior does not apply the same protection based on root_count.
Consequently, KVM can recursively prepare the page for zapping even though that page is still being used as a root. (GitHub)
The root is removed from the active list and marked invalid, but it cannot immediately be freed because a root reference remains.
Normally this should still be recoverable.
Zapscape becomes dangerous because the current page fault already completed its stale-root check before reclamation occurred.
Fault handling continues beneath the now-invalid root.
That is when the abnormal invalid child enters the active page list.
From Broken List State to Use-After-Free
The next stage is Linux list corruption.
KVM’s struct kvm_mmu_page contains a struct list_head used to attach the object to MMU management lists.
Under the Zapscape sequence, an invalid child can remain linked from the active list while later cleanup treats the same list link according to the object’s invalid state.
The result is effectively double membership: one list node becomes associated with inconsistent list ownership.
When the corresponding shadow-page object is subsequently freed, a list reference can remain behind.
That creates a dangling pointer.
Kim’s research describes the resulting state as a post-free write primitive derived from the dangling list link. (GitHub)
At this stage the vulnerability has crossed an important threshold.
This is no longer merely:
wrong MMU state -> guest crash
It has become:
wrong MMU state
↓
invalid active shadow page
↓
inconsistent list membership
↓
freed MMU object
↓
dangling kernel pointer
↓
post-free kernel write
Memory-corruption exploitation remains highly environment-dependent, but this is why the researcher’s demonstrated impact goes far beyond the relatively restrained wording of the initial CVE record.
How the Public Zapscape PoC Reaches Host Root
The public Zapscape demonstration goes further and converts the memory-corruption primitive into host kernel execution.
Kim’s write-up describes an exploitation chain involving controlled reuse of freed objects, recovery of the KASLR slide, and subsequent kernel execution paths. The final effect of the public demonstration is deliberately simple to verify: the vulnerable target host creates a file named /Zapscape with UID 0 and mode 0644. (GitHub)
The proof is therefore visible from the host:
-rw-r--r-- 1 root root ... /Zapscape
That file is a PoC artifact, not a universal Zapscape indicator of compromise.
A real attacker has no reason to reproduce the researcher’s proof marker. Defenders should not scan for /Zapscape and conclude that its absence means a system could not have been exploited.
The significant result is what the file proves: guest-triggered corruption was successfully transformed into an operation performed with host root authority.
What Privilege Does an Attacker Need Inside the Guest?
For the guest-to-host path demonstrated by the researcher, the attacker needs L1 kernel privilege.
In most practical terms, that means root or equivalent control of the L1 guest kernel.
This requirement is substantial, but it does not necessarily neutralize the cloud-security risk.
Cloud tenants are commonly administrators of their own virtual machines. Root inside a rented VM is therefore not equivalent to root on the physical host. Guest root is supposed to remain contained by the virtualization boundary.
Kim explicitly notes this distinction in the Zapscape FAQ: L1 kernel privilege is required, but tenants are commonly granted root inside the VM they control. (GitHub)
The intended isolation model is:
Tenant root inside L1
X
X must not cross
X
Host kernel root on L0
Zapscape is interesting precisely because the demonstrated exploit crosses that boundary.
Nested Virtualization Is the Major Exposure Condition
Nested virtualization is the ability for one VM to itself act as a hypervisor.
The Linux kernel documentation lists legitimate use cases including development environments, VM-image building, nested lab infrastructure, virtualization-based operating-system features, and workloads requiring guest hypervisors. (Linux Kernel Documentation)
It is also the major exposure condition for CVE-2026-64561.
For x86 KVM, nested virtualization has been enabled by default in upstream Linux since kernel 4.20, although distributions may override that default. The official KVM documentation provides the relevant module parameter checks. (Linux Kernel Archives)
This does לא mean that every VM automatically receives nested virtualization.
The L0 hypervisor or cloud configuration must expose the relevant CPU virtualization capabilities to L1.
Consequently, defenders should evaluate both:
- whether nested virtualization is enabled on the host; and
- whether untrusted guests actually receive the capabilities required to use it.
The second question is especially important in multi-tenant infrastructure.
AMD and Intel Do Not Have Identical Zapscape Requirements
Zapscape affects common KVM shadow-MMU logic, but the demonstrated trigger construction differs between AMD and Intel.
AMD
The public full-chain PoC targets AMD nested SVM/NPT.
Kim’s demonstration uses a vulnerable Linux 7.1.3 target and constructs a condition in which the same KVM shadow-page structure becomes both a child and a pinned root. AMD does not require an equivalent of Intel’s additional PWL4/PWL5 capability combination for the documented attack path. (GitHub)
This is why the currently released public PoC focuses on AMD.
Intel
Intel requires a narrower set of conditions.
According to the research, L0 must provide nested VMX and EPT, and L1 must see support for both four-level and five-level EPT page walks.
The attacker then needs to construct the corresponding EPT alias so that the same shadow page can be reused in the necessary root/child relationship. (GitHub)
This is not ordinary five-level linear-address paging.
Kim specifically emphasizes that the important detail is the EPT page-walk length that L1 can use for L2.
Therefore an Intel exposure assessment cannot stop at:
nested = Y
Nested virtualization is necessary, but the documented Intel path has additional capability requirements.
Why Zapscape Matters for Multi-Tenant Clouds
The most serious Zapscape scenario is a KVM-based environment in which mutually untrusted users receive virtual machines with nested virtualization.
Consider the isolation topology:
KVM L0 host
+--------------------------+
| |
| VM A VM B VM C|
| tenant A tenant B C |
| |
+--------------------------+
Ordinarily, compromise of VM A should remain confined to VM A.
A guest-to-host escape changes the trust model:
Compromised / malicious L1
|
| CVE-2026-64561
v
L0 host kernel
|
+------+------+
| |
other guests host control
Host kernel compromise can potentially expose resources belonging to other guests and the virtualization infrastructure itself.
The public Zapscape research explicitly identifies KVM/x86 environments accepting untrusted guests with nested virtualization—particularly multi-tenant environments—as the important security boundary. (GitHub)
That does not mean every public-cloud VM is vulnerable. Cloud providers differ in hypervisor architecture, CPU feature exposure, host kernel versions, patching processes and nested-virtualization implementations.
The proper conclusion is narrower:
Any organization intentionally exposing nested KVM functionality to untrusted x86 guests should prioritize CVE-2026-64561 exposure analysis.
Local Privilege Escalation Is a Second Risk Model
Zapscape is primarily interesting as a virtualization escape, but the research also describes a local privilege-escalation scenario.
On Linux systems where an unprivileged local process can open /dev/kvm, that process can itself create and operate virtual machines through the KVM API.
Kim notes that distributions where /dev/kvm is made broadly accessible can therefore expose a second attack model: instead of escaping from a separately administered tenant VM, a low-privileged local process may use KVM as the route toward host root. (GitHub)
The exact device permissions vary between distributions and deployments, so administrators should inspect the actual system rather than assuming a universal mode.
לדוגמה:
stat -c '%a %U %G %n' /dev/kvm
and:
ls -l /dev/kvm
If ACLs are used:
getfacl /dev/kvm
A permissive /dev/kvm configuration does not itself prove exploitation is possible. Kernel patch status and all other vulnerability conditions remain relevant.
It simply changes who can reach the KVM attack surface.
Which Linux Kernels Are Affected by CVE-2026-64561?
The kernel.org CNA record currently identifies Linux 5.9 as the semver starting point for the affected state that produces the security-relevant invariant violation.
The underlying invalid-root behavior is considerably older. Kernel.org notes that the root-tracking flaw traces back to 2008, but states that the “true badness” appeared in 2020 with Linux 5.9 when KVM adopted the invariant that invalid shadow pages cannot remain on the active list. (NVD)
The researcher’s commit-level range is:
Introduced security-relevant state:
f95eec9bed76
2020-07-08
Fixed mainline:
2abd5287f083
2026-07-21
Kim gives the same range in the public Zapscape repository. (GitHub)
The kernel.org CVE data lists the following fixed stable-branch versions:
| סניף | First fixed version recorded by kernel.org |
|---|---|
| Linux 6.6 | 6.6.148 |
| Linux 6.12 | 6.12.101 |
| Linux 6.18 | 6.18.42 |
| Linux 7.1 | 7.1.6 |
| Mainline development | 7.2-rc5 |
(NVD)
These numbers are useful for upstream Linux, but enterprise defenders should not turn them into a naïve scanner rule.
Do Not Determine Vendor Exposure from uname -r Alone
Linux distributions frequently backport vulnerability fixes.
A vendor might therefore ship a kernel whose external version number looks older than the first upstream fixed version while already containing the necessary patch.
Red Hat explicitly warns about this behavior in its CVE guidance. To preserve compatibility and stability, Red Hat commonly backports security fixes rather than rebasing the entire package, which can cause version-only vulnerability scanners to report false positives. (Red Hat Customer Portal)
This means:
uname -r
is useful inventory information.
It is not final vulnerability evidence.
A better decision model is:
Kernel package
+
vendor advisory / package status
+
presence of the upstream-equivalent fix
+
nested virtualization exposure
+
CPU-specific requirements
=
actual CVE-2026-64561 risk
For distribution-managed systems, the vendor’s package status should take precedence over an upstream-version comparison.
The CVE-2026-64561 Patch Is Surprisingly Small
The upstream remediation directly fixes the stale-root ordering problem.
Instead of checking the page-fault root before potentially reclaiming MMU pages, the fixed code first makes MMU pages available and then checks whether the current root has become stale.
Conceptually, the vulnerable sequence is:
if (is_page_fault_stale(vcpu, fault))
retry;
make_mmu_pages_available(vcpu);
fetch_using_root();
The corrected logic is:
make_mmu_pages_available(vcpu);
if (is_page_fault_stale(vcpu, fault))
retry;
fetch_using_root();
The change is simple but security-significant.
If reclaim invalidates the root, KVM now detects that fact after reclamation and restarts the page fault rather than constructing children below an invalid root.
Kim’s patch analysis explains that this prevents the invalid child from entering active_mmu_pages, breaking the sequence before double list membership, the dangling active-list reference and the post-free write can form. (GitHub)
The mainline fix is commit:
2abd5287f08319fa35764566b15c6e22cb1068db
The patch was merged on July 21, 2026. (GitHub)
CVE-2026-64561 Disclosure Timeline
Zapscape followed a coordinated disclosure process.
According to the researcher’s published timeline:
| Date | Event |
|---|---|
| July 11, 2026 | Vulnerability details and PoC reported to security@kernel.org |
| July 13 | Patch handling discussed with KVM maintainers |
| July 21 | Patch posted and mainline fix merged |
| August 1 | Vulnerability and exploit information submitted to linux-distros under a five-day embargo |
| August 4 | CVE-2026-64561 assigned |
| August 6 | Embargo ended; technical information and public exploit released |
(GitHub)
NVD lists August 4, 2026 as the publication date for the CVE record. (NVD)
The ordering is useful context for defenders: the upstream fix existed before the full exploitation details became public.
What Is the CVSS Score for Zapscape?
At the time of writing, NVD has not published its own CVSS score for CVE-2026-64561.
Red Hat currently provides a preliminary CVSS 3.1 score of 7.0:
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H
That translates to:
| מטרי | Red Hat value |
|---|---|
| וקטור התקפה | Local |
| Attack complexity | גבוה |
| Privileges required | נמוך |
| User interaction | אף אחד |
| סודיות | גבוה |
| יושרה | גבוה |
| Availability | גבוה |
The apparent tension between a 7.0 score and a demonstrated host escape is a useful reminder that CVSS is not a replacement for architecture-aware risk assessment.
Zapscape has meaningful prerequisites.
But when those prerequisites correspond to a service intentionally offered by the platform—such as nested virtualization for an untrusted tenant—the impact concerns one of the strongest boundaries in the infrastructure.
Zapscape vs Januscape
Zapscape follows another KVM escape disclosed by the same researcher: Januscape, CVE-2026-53359.
The two vulnerabilities should not be treated as aliases.
Kim states that they affect the same broader shadow-MMU area but have different root causes. (GitHub)
The Intel trigger conditions also differ.
For Zapscape, the documented Intel attack requires both four-level and five-level EPT page-walk capabilities to be exposed to L1.
Kim specifically contrasts this with Januscape, for which the Intel nested-virtualization conditions were less restrictive. (GitHub)
Zapscape is presented as the third part of the researcher’s “KVM Escape Trilogy”:
ITScape
CVE-2026-46316
↓
Januscape
CVE-2026-53359
↓
Zapscape
CVE-2026-64561
The strategic lesson is broader than any one CVE: nested virtualization significantly expands the amount of hypervisor state that hostile guest code can manipulate.
Safe Validation: Do Not Begin by Running the Zapscape PoC
The existence of a public exploit changes vulnerability management, but it does not mean production exploit execution is the correct validation technique.
CVE-2026-64561 can crash or compromise the KVM host by design.
Running the public PoC directly against an operational hypervisor risks impacting every workload sharing that machine.
For most organizations, safe CVE-2026-64561 validation should begin with configuration and patch-state verification, not exploitation.
Step 1: Identify the active kernel
uname -r
uname -a
For additional package information on Debian-family systems:
dpkg-query -W "linux-image-$(uname -r)" 2>/dev/null
On RPM-based distributions:
rpm -q kernel
rpm -q kernel-core 2>/dev/null
Record the exact package release, not just the upstream kernel family.
Step 2: Confirm whether the host actually uses KVM
lsmod | grep -E '^kvm'
Typical Intel output contains:
kvm_intel
kvm
AMD systems normally expose:
kvm_amd
kvm
No KVM module means this specific KVM/x86 attack surface is not active at that moment, although configuration and boot-time use still need to be considered during a complete inventory.
Step 3: Check nested virtualization
For Intel:
cat /sys/module/kvm_intel/parameters/nested
For AMD:
cat /sys/module/kvm_amd/parameters/nested
A value such as:
Y
indicates that nested virtualization is enabled at the KVM-module level.
The Linux KVM documentation explicitly recommends these parameters for determining nested virtualization status. It also notes that upstream Linux has enabled nested KVM by default since kernel 4.20, subject to distribution overrides. (Linux Kernel Archives)
Again, module-level enablement does not prove that every tenant VM receives nested virtualization.
Step 4: Determine whether untrusted L1 guests receive VMX or SVM
Inventory the actual VM configuration.
For libvirt-managed guests, inspect VM CPU configuration and the generated QEMU command line. The Linux kernel’s nested-KVM troubleshooting documentation recommends collecting both L0 and L1 kernel, libvirt and QEMU versions together with the actual command lines used for L1 and L2. (Linux Kernel Documentation)
A configuration using CPU host passthrough deserves particular attention because it may expose virtualization features depending on the surrounding hypervisor policy.
Do not assume that:
nested enabled on L0
automatically equals:
nested available inside every L1
Verify the guest-facing CPU model.
Step 5: Treat Intel separately
If the host is Intel, simply finding nested=Y is not sufficient to establish the documented Zapscape exploitability.
The public research requires:
nested VMX
+
EPT
+
EPT page-walk length 4 exposed to L1
+
EPT page-walk length 5 exposed to L1
and an L1-controlled EPT relationship that creates the required shadow-page alias. (GitHub)
If five-level EPT capability is not exposed to the untrusted L1 environment, that is an important reduction in the documented Intel attack surface.
It should not, however, replace patching.
Step 6: Check /dev/kvm חשיפה
ls -l /dev/kvm
stat -c '%A %a %U %G %n' /dev/kvm
Then determine which local identities can access it.
This matters for the separate local-privilege-escalation model discussed by the researcher.
Step 7: Verify the vendor fix
Compare the exact installed kernel package with the security tracker maintained by your Linux vendor.
For upstream kernels, kernel.org currently identifies these stable fixed versions:
6.6.148
6.12.101
6.18.42
7.1.6
7.2-rc5
(NVD)
For vendor kernels, look for a confirmed backport of the CVE-2026-64561 fix rather than demanding those exact version numbers.
Step 8: Reboot into the fixed kernel
Installing a kernel package is not sufficient if the vulnerable kernel remains active.
Verify after the maintenance reboot:
uname -r
and compare the running kernel against the intended patched package.
How to Reproduce Zapscape Safely in a Research Lab
Some security teams legitimately need exploit-level verification rather than exposure inference.
The public researcher explicitly recommends QEMU TCG for safe Zapscape testing. (GitHub)
That recommendation matters because TCG provides CPU emulation rather than directly exposing the researcher’s vulnerable target to the physical machine’s KVM host.
The research setup conceptually looks like:
Physical research workstation
|
| QEMU TCG
v
+---------------------------+
| Emulated L0 Linux 7.1.3 |
| vulnerable KVM target |
+---------------------------+
|
v
+---------------------------+
| PoC-created L1 |
+---------------------------+
|
v
+---------------------------+
| L2 nested workload |
+---------------------------+
The exploit’s “host” is therefore the intentionally vulnerable Linux environment running inside the emulation boundary.
This is fundamentally safer than executing a guest-to-host exploit against a production bare-metal KVM machine.
A responsible lab should additionally be disposable, isolated from sensitive networks, backed by snapshots or reproducible images, and contain no production credentials or customer workloads.
Why Production PoC Testing Is Usually the Wrong Question
Security teams often ask:
“Can we prove the server is vulnerable by running the exploit?”
For Zapscape, this can be the wrong objective.
The useful question is:
“Can an attacker-controlled workload reach the vulnerable KVM path, and is the host missing the fix?”
If the answer is already demonstrably yes from configuration and package evidence, intentionally corrupting the production hypervisor rarely adds meaningful risk information.
That principle is especially important for virtualization vulnerabilities because “successful verification” can itself violate tenant availability and isolation.
In authorized CVE-validation workflows, platforms such as Penligent’s agentic penetration testing platform can help organize evidence collection and verification, but the validation policy should still distinguish non-destructive exposure checks from exploit execution. For a hypervisor escape such as CVE-2026-64561, kernel/package evidence, configuration inspection and isolated reproduction are generally safer evidence sources than triggering memory corruption on a production host.
Can You Mitigate Zapscape by Disabling Nested Virtualization?
If nested virtualization is not required, disabling its exposure to untrusted workloads significantly reduces the demonstrated guest-to-host attack surface.
For Intel, the relevant KVM functionality is controlled through kvm_intel‘s nested setting.
The kernel command-line documentation describes:
kvm-intel.nested=
as the control for nested virtualization in KVM/VMX. (Kernel.org)
Equivalent handling exists for AMD’s nested SVM functionality.
Changing this on a live production hypervisor is not something to perform casually. Existing nested workloads can depend on the capability, and unloading KVM modules is generally incompatible with running VMs.
The practical mitigation sequence is therefore normally:
Identify hosts
↓
identify workloads needing nested virtualization
↓
patch wherever possible
↓
where patching cannot be immediate,
remove nested exposure from untrusted workloads
↓
schedule reboot / host maintenance
Disabling nested virtualization should be treated as a compensating control, not a substitute for applying the kernel fix.
Kernel Hardening Can Change the Exploit Outcome
The public PoC also highlights the value—and limits—of kernel hardening.
Kim states that the demonstration environment has CONFIG_DEBUG_LIST, CONFIG_LIST_HARDENED, ו CONFIG_BUG_ON_DATA_CORRUPTION disabled. With list hardening enabled, the specific post-free list write used by the public exploit is blocked and the outcome becomes a denial of service instead. (GitHub)
That is meaningful defense in depth.
It is not equivalent to fixing CVE-2026-64561.
A malicious guest being able to crash the host kernel still breaks a major virtualization security guarantee, particularly on a multi-tenant server.
And a public PoC’s exploitation method is not necessarily the only possible way to use a memory-corruption vulnerability.
The correct order remains:
Patch the bug
+
reduce nested virtualization exposure
+
retain kernel hardening
rather than relying on the hardening configuration as the primary remediation.
Detecting Zapscape Exploitation
There is currently no strong generic IOC comparable to a malicious file hash, network domain or protocol signature.
The vulnerability is exercised through KVM state manipulated by an L1 guest.
ה /Zapscape file created by the researcher’s demonstration is merely the PoC’s success marker.
Therefore:
No /Zapscape file
does לא mean:
No exploitation occurred
Organizations should instead approach detection at the hypervisor and workload levels.
Unexpected KVM host crashes associated with nested workloads deserve investigation. So do host kernel memory-corruption warnings, list-corruption failures and unexplained instability concentrated around nested-virtualization workloads.
Because these signals are not Zapscape-specific, they should be treated as investigation triggers rather than CVE signatures.
What to Preserve After a Suspicious KVM Host Crash
The Linux KVM documentation provides a useful baseline for nested-virtualization debugging.
For suspicious systems, preserve at minimum:
L0 kernel version
L1 kernel version
L0 QEMU/libvirt versions
L1 QEMU/libvirt versions
L1 full QEMU command line
L2 full QEMU command line
L0 dmesg
L1 dmesg
L0 lscpu
L1 lscpu
CPU feature configuration
nested virtualization policy
host kernel package history
The kernel documentation recommends many of these same artifacts when reporting nested KVM failures because debugging the environment otherwise becomes extremely difficult. (Linux Kernel Documentation)
If kernel crash dumps are enabled, preserve the vmcore before rebuilding or recycling the host.
In a cloud environment, also preserve the mapping between affected host, tenant instances and nested-virtualization configuration so that investigators can reconstruct which guests had access to the relevant virtualization capabilities.
Patch Priority for CVE-2026-64561
Not every Linux host needs the same emergency priority.
A useful operational ranking looks like this:
| סביבה | Suggested priority |
|---|---|
| Multi-tenant KVM host exposing nested virtualization to untrusted guests | Critical operational priority |
| KVM cloud host where nested virtualization may be exposed | Urgent verification and patching |
| Internal KVM host with nested virtualization and semi-trusted workloads | גבוה |
| Developer workstation with nested KVM | Medium to high depending on local code trust |
| KVM host with nested virtualization disabled for all untrusted workloads | Reduced immediate exploitability, but still patch |
| Linux host not using x86 KVM | CVE path not applicable |
| Kernel confirmed to contain vendor backport | No longer vulnerable to the fixed path |
This is a risk-prioritization model rather than a vendor severity rating.
The high priority assigned to some environments comes from the boundary at risk: guest root is intentionally less trusted than host kernel root.
Why Public PoC Availability Changes the Patching Window
Before August 6, defenders could rely on an information asymmetry: maintainers and selected distribution security teams had the fix while full public exploitation details were embargoed.
That asymmetry is gone.
The vulnerability architecture, affected code, root-cause analysis and proof of concept are now public. (GitHub)
The public PoC is not immediately portable to arbitrary cloud providers. Kim states that real-world use would require moving current L1 actions into a guest kernel module and adapting the exploit to the target host kernel configuration and memory backend. (GitHub)
That is an important constraint.
It is not a reason for prolonged patch deferral.
Once a full memory-corruption chain and working proof are public, defenders should assume that additional exploit engineering is possible.
A Practical CVE-2026-64561 Validation Checklist
For security teams evaluating Zapscape today, the decision can be reduced to a small number of defensible questions:
- Is this an x86 Linux host using KVM?
- Does its kernel contain the CVE-2026-64561 fix or a vendor backport?
- Is nested virtualization enabled?
- Is nested virtualization actually exposed to untrusted L1 guests?
- For Intel, does L1 receive both required EPT page-walk capabilities?
- Can untrusted local users access
/dev/kvm? - Has the system rebooted into the fixed kernel?
- Are there unexplained KVM host crashes or memory-corruption events that warrant incident investigation?
If question two confirms a vendor-supported fixed kernel, exploit testing is normally unnecessary.
If the kernel is vulnerable but nested virtualization is unavailable to untrusted guests, immediate guest-to-host exposure is substantially reduced, but patching should remain scheduled.
If the kernel is vulnerable ו untrusted tenants receive nested virtualization, the system should be treated as a high-priority hypervisor remediation target.
Frequently Asked Questions
Is CVE-2026-64561 a real KVM escape?
Yes. The public Zapscape research demonstrates a complete guest-to-host exploitation chain against an AMD nested-KVM setup and produces an observable root-owned file on the target host. (GitHub)
Does Zapscape affect QEMU?
The vulnerability itself is in Linux KVM’s in-kernel x86 shadow MMU, not QEMU device emulation. QEMU is used in the public laboratory demonstration. (GitHub)
Does an attacker need root inside the VM?
For the demonstrated guest escape, the attacker requires L1 kernel privilege. Guest root is commonly available to the tenant administering its own VM, which is why this prerequisite does not eliminate the risk in nested-virtualization services. (GitHub)
Is nested virtualization required?
Yes for the documented guest-to-host Zapscape path. Nested EPT/NPT shadowing is central to the trigger.
Is AMD affected?
Yes. The published full exploit demonstration targets AMD SVM/NPT. (GitHub)
Is Intel affected?
The underlying shared shadow-MMU vulnerability applies to Intel as well, but the documented Intel trigger has additional conditions: nested VMX/EPT must be enabled and both four-level and five-level EPT page-walk capabilities must be exposed to L1. (GitHub)
Is Linux 5.8 vulnerable?
The kernel.org CNA record currently defines Linux versions earlier than 5.9 as unaffected by the security-relevant version of this bug, even though an older underlying root-management flaw existed before then. (NVD)
Is Linux 6.6 vulnerable?
It depends on the exact release or vendor backport. Upstream kernel.org records 6.6.148 as the fixed point for the 6.6 stable branch. Distribution kernels may have backported the fix under another package version. (NVD)
Is the Zapscape PoC public?
Yes. The researcher’s repository contains demonstration code and a detailed technical write-up. (GitHub)
Has CVE-2026-64561 been exploited in the wild?
No public evidence reviewed as of August 7, 2026 establishes in-the-wild exploitation. Public reporting specifically notes that the research disclosure does not claim active exploitation. (חדשות ההאקרים)
Should I run the public PoC against my production hypervisor?
No. The exploit intentionally attacks host kernel memory integrity. Configuration, patch and capability validation are safer ways to establish production exposure. If exploit-level reproduction is required for authorized research, the researcher recommends a QEMU TCG-based isolated environment. (GitHub)
Final Assessment
CVE-2026-64561 Zapscape is a genuine KVM/x86 guest-to-host escape vulnerability, but its severity needs to be understood through architecture rather than headline alone.
The bug begins with a surprisingly small ordering mistake. KVM checks whether an MMU root is stale, then performs an operation capable of invalidating that same root, and later continues using the result of the earlier check.
Nested shadow-MMU behavior turns that mistake into an invalid child shadow page.
Broken lifecycle assumptions turn the invalid page into inconsistent list state.
The inconsistent list state can produce a dangling kernel reference and post-free write.
The published Zapscape research demonstrates that this primitive can ultimately cross the guest-host isolation boundary and execute with host root authority. (GitHub)
At the same time, the vulnerability has clear conditions. It is not a remote internet exploit against arbitrary Linux servers. The demonstrated escape requires an attacker-controlled nested-virtualization environment and L1 kernel privilege; Intel adds further EPT requirements.
Those conditions make accurate exposure mapping possible.
They do not make patching optional.
For KVM environments that intentionally expose nested virtualization to untrusted tenants, CVE-2026-64561 should be treated as a high-priority host security issue. Update to a vendor kernel containing the upstream fix, verify that the fixed kernel is actually running, remove nested virtualization from untrusted workloads where it is unnecessary, and reserve PoC execution for disposable isolated research environments.
The most useful validation outcome is not seeing /Zapscape appear on a host.
It is being able to demonstrate, with evidence, that the vulnerable state can no longer be reached.
Hebrew 
English 
German 
French 
Spanish 
Portuguese 
Japanese 
Korean 
Hindi 
Arabic 
Turkish