The disclosure of a new Linux KVM vulnerability named Zapscape demonstrates how a flaw in virtual-memory management can allow a privileged attacker inside a guest virtual machine to cross the virtualization boundary and execute code on the underlying host. Tracked as CVE-2026-64561, the vulnerability affects KVM’s x86 shadow memory-management unit and becomes reachable when nested virtualization is enabled for untrusted guest systems. The public proof of concept shows that successful exploitation can create a file owned by root on the host, demonstrating that the issue can progress beyond a virtual-machine crash into host-level code execution. 

Virtualization security depends on the assumption that code running inside a guest cannot directly influence the host kernel or other virtual machines sharing the same physical system. A guest administrator may have complete authority inside their own virtual machine, but that authority should end at the virtualization boundary. Zapscape breaks this assumption by allowing actions performed inside a nested guest environment to corrupt memory structures maintained by the host’s KVM subsystem.

The vulnerability is especially relevant to cloud providers, hosting companies, security laboratories and development platforms that allow customers to run their own hypervisors inside rented virtual machines. This nested virtualization capability is useful for testing operating systems, running Android emulators, building virtualized development environments and operating private cloud platforms. It also exposes additional KVM functionality to the guest, expanding the attack surface available to a malicious tenant.

Zapscape is not an ordinary application vulnerability and does not involve QEMU incorrectly emulating a virtual device. The flaw exists inside the Linux kernel’s KVM implementation and can be triggered through guest-controlled memory-management activity. This means replacing QEMU or restricting access to one emulated hardware device would not correct the underlying problem. The Linux kernel running on the physical host must contain the appropriate KVM fix.

The flaw affects KVM’s shadow MMU

KVM uses memory-management mechanisms to translate addresses used by a guest virtual machine into physical memory locations on the host. Modern processors provide hardware-assisted translation technologies such as Intel Extended Page Tables and AMD Nested Page Tables, which improve performance and reduce the amount of translation work performed by the hypervisor.

Nested virtualization adds another level of complexity because the L1 guest may itself operate an L2 virtual machine. KVM must then emulate or manage additional layers of page translation so the nested guest believes it is running under its own hypervisor. Under certain configurations, this requires KVM’s shadow memory-management unit to maintain shadow page tables representing the nested translation relationships.

These shadow pages contain information used by the host kernel to translate guest memory safely and efficiently. They also include internal bookkeeping structures that track whether a page is active, stale, reusable or awaiting removal. A mistake in managing the lifetime of one of these structures can cause KVM to continue using memory after it has already been invalidated or released.

Zapscape arises from precisely this type of lifetime-management failure. During a guest-triggered page fault, KVM checks whether the current shadow MMU root remains valid. It may then attempt to reclaim memory by making additional MMU pages available. That reclamation process can invalidate the same root that the fault-handling path is still using.

The problem is the order in which the checks occur. KVM checks whether the root is stale before performing the reclamation operation, but it does not repeat the check afterward. If the reclamation process invalidates the root, KVM continues handling the page fault under an object that is no longer valid.

The resulting condition can develop into a use-after-free vulnerability, in which the kernel continues reading or writing through a pointer associated with memory that has already been released or repurposed.

Invalid shadow pages remain on active lists

After the root becomes invalid, KVM may continue creating child shadow pages beneath it. Those child pages inherit the invalid state of the parent but are nevertheless placed on KVM’s active MMU page list.

This creates inconsistent bookkeeping because the same page may later become associated with more than one internal list. During cleanup, KVM can attach the same list link to two locations, release the page and then continue using stale references that still point to the freed memory.

The stale link can produce post-free writes, allowing an attacker to corrupt nearby kernel memory. With sufficient control over allocation patterns and the data placed into those memory regions, the attacker may be able to turn the memory corruption into controlled execution inside the host kernel.

Use-after-free vulnerabilities are particularly dangerous in kernel and hypervisor code because the affected process already operates with the highest privileges available on the system. Successful exploitation does not merely compromise one application account. It can give the attacker authority over the entire physical host.

The public exploit demonstrates host-level impact

The researcher’s public proof of concept targets AMD nested virtualization using Secure Virtual Machine and Nested Page Tables. It demonstrates successful exploitation by creating a file named `/Zapscape` on the Linux host with root ownership.

Creating this file provides visible evidence that commands initiated from the guest were executed with host-level privileges. The proof of concept therefore goes beyond triggering a kernel warning or denial of service and shows that the memory-corruption primitive can be developed into a complete guest-to-host escape.

The demonstration targets Linux kernel 7.1.3 under a specific AMD configuration. It is not described as an immediate universal exploit capable of compromising every vulnerable cloud host without modification. Real-world exploitation would require adapting the technique to the target kernel configuration, memory backend and virtual-machine environment.

The attacker would also need to move the required nested-guest actions into code capable of running within the target L1 virtual machine, such as a guest kernel module. These requirements increase the technical difficulty but do not reduce the importance of the vulnerability for environments that deliberately expose nested virtualization to customers or other untrusted users.

Public proof-of-concept code lowers the barrier for further research and offensive development. Skilled attackers can study the memory-corruption chain, adapt it to additional kernel builds and improve reliability. Organizations should therefore not wait for confirmed exploitation before applying the available updates.

Guest root access is required

The demonstrated attack requires kernel-level privileges inside the L1 guest, which usually means root or equivalent administrative control over that virtual machine.

In many security contexts, requiring guest root would be considered a significant limitation. In public infrastructure-as-a-service environments, however, customers normally receive root access to the virtual machines they rent. A malicious customer can therefore satisfy this requirement legitimately without first compromising the guest.

The virtualization boundary is specifically intended to remain secure even when the guest operating system and every application inside it are hostile. Cloud providers must assume that customers can load kernel modules, manipulate page tables and generate unusual virtual-machine activity inside their assigned instances.

A guest escape requiring root is therefore still a serious vulnerability in multi-tenant environments. The guest administrator is trusted to control only the rented virtual machine, not the physical server or neighboring tenants.

The attack may also become relevant after a separate intrusion. An attacker who compromises an ordinary application inside a guest may first escalate privileges to guest root and then use Zapscape to reach the host. Modern attacks frequently chain multiple vulnerabilities rather than depending on one flaw to provide every stage of access.

Nested virtualization creates the exposure

Zapscape requires nested virtualization to be exposed to the attacker-controlled L1 guest. Hosts that do not permit guests to operate nested virtual machines are not exposed through the demonstrated path.

Nested virtualization is commonly enabled by loading the Intel or AMD KVM modules with the appropriate nested option and exposing virtualization features to selected guests. Cloud platforms may offer specialised instance types designed for running hypervisors, emulators or virtualization-based development tools.

Organizations should determine whether nested virtualization is enabled intentionally or merely inherited from a default configuration. A host may expose the capability even though no supported workload currently requires it.

Where nested virtualization is unnecessary, disabling it provides an effective temporary mitigation while kernel updates are being tested and deployed. On Intel systems, this generally involves disabling the nested option for the `kvm_intel` module, while AMD environments use the corresponding `kvm_amd` setting.

Administrators must confirm the active configuration rather than relying solely on static configuration files. A module may already be loaded with nested virtualization enabled and remain active until the host is restarted or the module is safely reloaded.

Disabling nested virtualization can interrupt workloads that depend on it, including Android emulators, nested Kubernetes platforms, virtualized security laboratories and private cloud software. Changes should therefore be coordinated with workload owners and validated before broad deployment.

Intel exploitation has additional requirements

The vulnerability affects KVM’s x86 shadow-MMU implementation and is relevant to both Intel and AMD virtualization, but the demonstrated requirements differ between the two processor families.

On Intel hosts, the L1 guest must be exposed to both four-level and five-level Extended Page Table walking capabilities. These conditions determine which nested page-table paths become available to the guest and whether it can reach the vulnerable shadow-MMU behaviour.

AMD does not have an equivalent requirement in the disclosed attack model, making the nested SVM path more directly reachable when nested virtualization is available.

These technical distinctions mean that not every vulnerable kernel and processor configuration is equally exploitable. Organizations should nevertheless follow their Linux vendor’s advisory rather than attempting to dismiss exposure based on a partial reading of the proof of concept.

Kernel vulnerabilities frequently receive additional exploit paths after disclosure. A configuration that prevents the current public demonstration may still contain the underlying use-after-free and could become exploitable through a modified technique.

QEMU is not the vulnerable component

The public proof of concept can be tested safely using QEMU’s Tiny Code Generator mode, but QEMU itself is not responsible for the vulnerability.

QEMU provides userspace virtual-machine emulation and device models, while KVM allows the Linux kernel and hardware virtualization extensions to execute guest code efficiently. Zapscape exists in KVM’s in-kernel shadow-memory-management logic.

This distinction matters for remediation because updating QEMU alone will not correct the vulnerable kernel code. Administrators must install a fixed Linux kernel or a distribution package containing the backported KVM patch.

Security scanners and asset inventories should therefore identify the kernel package and active KVM modules rather than focusing only on the QEMU version installed on the host.

Some commercial virtualization and cloud platforms embed KVM beneath their own management layer. Administrators may not interact with KVM directly, but the underlying host can still be affected. Customers should obtain remediation guidance from the platform vendor and confirm whether the kernel fix has been deployed.

The correction changes the ordering of validation

The upstream fix modifies the page-fault path so KVM checks whether the shadow MMU root has become stale after the memory-reclamation operation.

If reclamation invalidates the current root, KVM no longer continues creating or fetching shadow pages beneath it. Instead, the fault handler returns a retry condition and restarts the operation using valid state.

The correction is conceptually straightforward: the security-sensitive condition must be checked after the operation capable of changing it, not only before.

This reflects a broader class of ordering vulnerabilities. A program can verify that an object is valid, perform another operation that changes the object’s lifetime and then continue using the original result as though nothing happened. The earlier validation becomes meaningless because the state has changed between the check and use.

Moving one check may appear minor in the source code, but it restores the lifetime guarantee required by the surrounding shadow-MMU logic. Kernel security frequently depends on small ordering details that ordinary application code can afford to handle less rigorously.

Affected kernel versions are broad

The vulnerability affects Linux kernel versions beginning with 5.9 and continuing until the correction was included in stable branches. Fixed upstream releases include versions 6.6.148, 6.12.101, 6.18.42, 7.1.6 and the relevant 7.2 release candidate.

Organizations should not determine exposure solely by comparing the output of `uname -r` with these upstream version numbers. Enterprise Linux distributions often backport individual security fixes into older kernel branches without changing the main version to match the upstream release.

A Red Hat, Ubuntu, Debian, SUSE or other vendor kernel may therefore be protected even when its version appears older. Conversely, a custom-built kernel based on a newer branch may remain vulnerable if it does not contain the required commit.

Administrators should consult the security tracker or advisory issued by their Linux distribution and verify the exact package release installed on each host.

The correction was merged upstream through commit `2abd5287f083`. Organizations maintaining custom kernels should confirm that this change or an equivalent backport is included in their source tree.

Installing a new kernel package is not sufficient by itself. The physical host must boot into the corrected kernel before the vulnerable KVM code is replaced. Systems awaiting reboot should remain classified as exposed.

Multi-tenant cloud hosts face the greatest risk

The highest-risk environments are KVM hosts that run virtual machines belonging to mutually untrusted customers while allowing nested virtualization.

A malicious tenant could rent one eligible instance, obtain guest root through the normal service model and attempt to exploit the host. Successful host-level access could expose management credentials, storage backends and other virtual machines running on the same physical server.

The exact impact would depend on the cloud architecture and the privileges of the compromised host. Attackers may attempt to inspect guest memory, access virtual disks, modify host networking or use management credentials to expand into additional systems.

Even when the exploit causes only a host crash, one malicious tenant could create denial of service for every customer sharing that server. Availability impact alone can be significant in densely consolidated environments.

Cloud providers should prioritise patched kernels across hosts offering nested virtualization and should consider temporarily disabling the capability where updates cannot be deployed immediately.

Providers should also review whether nested-enabled instances are isolated into dedicated pools. Separating these workloads from ordinary tenant hosts can reduce the number of systems exposed to specialised virtualization attack paths.

Private cloud and development systems are also affected

The risk is not limited to large public cloud platforms. Enterprises may enable nested virtualization in internal OpenStack, Proxmox, KVM or development environments so teams can run test hypervisors and virtualised laboratories.

Development and security teams frequently receive broad guest privileges because their work involves operating kernels, emulators and network appliances. These environments may also contain sensitive source code, test credentials and connections to corporate systems.

An attacker compromising one nested-enabled development VM could attempt to escape to the physical host and then reach other internal workloads.

Organizations should identify which virtual machines receive nested virtualization and whether every assignment remains necessary. The capability should be enabled only for specific approved workloads rather than globally across all guests.

Hosts running untrusted testing or malware-analysis workloads deserve particular attention. Security laboratories may intentionally execute hostile code inside nested guests and depend heavily on the hypervisor boundary to contain it.

Local privilege escalation may be possible in some configurations

Although Zapscape is primarily described as a guest-to-host escape, KVM vulnerabilities can sometimes also provide a local privilege-escalation route on the host.

A local unprivileged user with access to `/dev/kvm` may be able to create a virtual machine, exercise the vulnerable KVM functionality and attack the kernel from the same physical system.

The feasibility depends on device permissions, required nested capabilities and the exact exploit implementation. Some Linux distributions or virtualization platforms grant access to `/dev/kvm` through a dedicated group, while others expose it more broadly.

Administrators should review which users and services can open `/dev/kvm`. Access should be limited to identities that genuinely require hardware-assisted virtualization.

Development tools, emulators and container workloads should not receive KVM access automatically. Granting a process access to the hypervisor interface substantially expands the kernel attack surface available to it.

Restricting `/dev/kvm` permissions is a useful defence-in-depth measure, but patching remains necessary for systems that provide legitimate virtualization services.

Guest isolation must assume hostile kernels

The vulnerability reinforces a fundamental principle of virtualization security: the hypervisor must remain secure even when the guest kernel is malicious.

Guest-level controls such as antivirus, secure boot and operating-system hardening may reduce the likelihood that an ordinary workload becomes compromised, but they do not protect a cloud provider from a customer who intentionally operates a hostile guest.

Hypervisor security must therefore validate every structure, transition and memory-management request received from the guest, regardless of whether it appears consistent with normal operating-system behaviour.

Nested virtualization makes this requirement more difficult because the L1 guest is itself attempting to manage an L2 guest. KVM must emulate privileged virtualization operations while ensuring that the L1 hypervisor cannot manipulate host state.

The complexity of shadow page tables, nested fault handling and multi-level translation creates a rich environment for lifetime, ordering and reference-counting bugs.

Organizations enabling nested virtualization should recognise that they are exposing some of the most complex code in the hypervisor to untrusted inputs.

Host monitoring may provide limited detection

Detecting exploitation of a KVM use-after-free is difficult because much of the malicious activity occurs inside kernel memory-management operations.

The public proof of concept creates a root-owned file on the host, which provides an obvious indicator during testing. A real attacker would likely replace this demonstration with quieter post-exploitation behaviour and avoid leaving a conveniently named `/Zapscape` artifact.

Kernel crashes, warnings, corrupted MMU lists and unusual KVM activity may provide signs of failed exploitation. Logs should be collected remotely because a successful host attacker can alter or delete local evidence.

Host-based intrusion detection should monitor unexpected root-level file creation, services, accounts and outbound connections. However, these indicators reflect post-compromise behaviour rather than the initial guest escape.

Virtualization platforms can also monitor which guests use nested virtualization and whether they generate abnormal rates of nested page faults, MMU reclamation or VM configuration changes. Such signals may support investigation but are unlikely to provide a universal reliable detection rule.

Prevention through kernel updates and capability restriction remains more dependable than attempting to detect the memory corruption after it begins.

Incident response must cover every hosted guest

If exploitation is suspected, the physical KVM host should be isolated and treated as fully compromised.

Host root access can allow an attacker to inspect or modify virtual machines, access storage credentials, tamper with network traffic and steal management tokens.

Every guest running on the affected host during the compromise period may therefore require investigation, even if the attacker originally controlled only one VM.

Virtual-disk integrity, guest snapshots, hypervisor management logs and network activity should be reviewed. Credentials stored on the host or used to communicate with orchestration platforms must be rotated from a trusted system.

Simply migrating the visible guest workloads away and rebooting the host may not be sufficient if the attacker has modified persistent storage, startup configuration or management systems.

Where host integrity cannot be established, rebuilding from a trusted image is safer than attempting selective cleanup. The replacement host should run a corrected kernel before any workloads return.

Cloud operators should also determine whether host-level credentials allowed the attacker to reach the control plane or other compute nodes.

Live migration and high availability can support patching

Virtualization operators often delay kernel updates because rebooting a KVM host interrupts every guest running on it.

Live migration can reduce this operational impact by moving virtual machines to patched hosts before the vulnerable server is restarted.

However, migration planning must ensure that workloads are not simply moved between equally vulnerable hosts. A sufficient pool of corrected capacity must be available before evacuation begins.

Hosts supporting nested virtualization may also have workload compatibility requirements that restrict migration targets. Operators should test whether nested-enabled guests can migrate safely between processor generations and configurations.

Where live migration is unavailable, organizations should use planned maintenance windows and communicate expected disruption. The presence of a public guest-to-host exploit justifies accelerated maintenance even when availability planning becomes inconvenient.

Live-patching services may eventually provide corrections without immediate reboot, but administrators must verify that the specific KVM change is covered. Installing or enabling a live-patch agent does not guarantee that every vulnerability can be corrected safely while the kernel remains active.

Templates and recovery systems must be updated

Virtualization hosts rebuilt from outdated images may reintroduce the vulnerable kernel after the production fleet has been patched.

Organizations should update bare-metal provisioning images, cloud-init templates, recovery media and infrastructure-as-code definitions.

Standby hosts and disaster-recovery sites must also be reviewed. A dormant server may appear harmless while offline but can become an exposed production host during failover.

Configuration management should enforce both the corrected kernel and the intended nested-virtualization policy. Hosts should not silently re-enable nested support after updates or reboot unless the workload requires it.

Asset inventories should identify processor vendor, kernel package, KVM module configuration and which guests receive virtualization extensions. Without this information, security teams may be unable to determine which hosts are actually reachable through the disclosed path.

The vulnerability follows other recent KVM escapes

Zapscape follows several other KVM vulnerabilities disclosed during 2026, including Januscape on x86 shadow MMU and ITScape on ARM64 interrupt-controller emulation.

These issues are technically distinct, but together they illustrate the security pressure placed on complex virtualization code.

Januscape involved reuse of incompatible shadow pages and affected both Intel and AMD hosts under nested virtualization. ITScape demonstrated a guest-to-host escape through ARM64 virtual interrupt handling. Zapscape introduces another use-after-free path within x86 shadow-MMU reclamation.

The concentration of discoveries does not necessarily mean that KVM is uniquely insecure. Increased research attention, including Google’s kvmCTF programme, encourages researchers to examine difficult hypervisor code and disclose previously unknown flaws.

However, operators should recognise that hypervisor patching is an ongoing operational requirement rather than a rare emergency. Virtualization hosts need the same disciplined vulnerability-management process applied to internet-facing applications and network appliances.

The broader cybersecurity lesson

Zapscape demonstrates how the security of multi-tenant infrastructure depends on precise memory-lifetime decisions deep inside the host kernel.

The guest does not need access to the host filesystem or an administrative account on the physical server. It manipulates nested memory-management operations until KVM invalidates a shadow root, continues using it and eventually corrupts host memory.

The attack succeeds because one validity check occurs before an operation capable of changing the condition being checked. That small ordering mistake undermines the isolation boundary supporting entire virtualized environments.

Organizations using KVM should install the corrected kernel package supplied by their Linux vendor and reboot affected hosts into the updated release. Hosts exposing nested virtualization to untrusted guests should receive the highest priority.

Where immediate patching is impossible, nested virtualization should be disabled for untrusted workloads. Access to `/dev/kvm` should also be restricted to authorized users and services.

Security teams must verify the active kernel, not merely the installed package, and update provisioning images, standby hosts and disaster-recovery systems.

The vulnerability should not be exaggerated as an immediate remote compromise of every Linux KVM server. The attacker requires privileged control inside an L1 guest, nested virtualization must be enabled and practical exploitation may require adaptation to the host environment.

Those conditions are nevertheless normal in several public cloud and development scenarios. A customer with guest root is not an exceptional event. It is the standard service offering.

Hypervisor isolation exists precisely to protect the host from fully controlled guests. When a guest can convert ordinary nested page faults into host kernel memory corruption, requiring guest root does not make the boundary failure acceptable.

Zapscape reinforces that nested virtualization is a powerful capability that should be exposed deliberately, monitored carefully and removed when unnecessary. Every additional layer of virtualisation adds useful flexibility, but also forces the host kernel to process more complex and attacker-controlled state.

Virtual machines are valuable because they allow mutually untrusted workloads to share hardware safely. The public exploit for CVE-2026-64561 shows that this safety ultimately rests on low-level bookkeeping structures and the order of a few kernel operations.

The fix is available, the proof of concept is public and the affected environments can be identified. KVM operators should therefore patch before an attacker turns a research demonstration into a considerably less educational cloud incident.

Zapscape, a new Linux kernel vulnerability, could allow an attacker with kernel privileges inside an L1 guest virtual machine (VM) to escape KVM isolation and execute code on the host. The risk applies when nested virtualization is exposed to untrusted guests. The flaw is tracked as CVE-2026-64561 and affects KVM/x86's shadow memory management unit (MMU), which manages shadow page

Source: New Zapscape KVM Flaw Could Let Privileged L1 Guest Code Escape to Linux Hosts via The Hacker News — published 06 Aug 2026.