Information was recently released about a vulnerability that puts cloud servers at risk. This vulnerability allows attackers to take complete control of the physical machine , a nightmare scenario for cloud infrastructure providers.
Zapscape, registered under the identifier CVE-2026-64561, is a critical vulnerability in the Linux KVM hypervisor that exposes a risk many platforms inadvertently assume by enabling nested virtualization. This vulnerability allows an attacker with kernel privileges in a virtual machine (L1) to execute code with root privileges on the host system (L0), breaking the isolation of virtualized environments.
Considered a high-impact threat, Zapscape not only facilitates escape from the virtual machine, but also opens a local privilege escalation route for host users who have write permissions on the /dev/kvm device.
Although organizations like Red Hat have rated the vulnerability with a CVSS score of 7.0 focusing on instability and denial of service, the public proof of concept (PoC) demonstrates a much more destructive scope: the creation of an arbitrary file directly in the root of the host.
Chaos in the memory management unit
The way Zapscape operates is hidden within KVM's Memory Management Unit (MMU) and how the hypervisor handles page tables when one guest (L1) acts as a hypervisor for another sub-guest (L2). The problem lies in a logical ordering error during page fault handling. In the kernel code paths, the check for an "obsolete root" was executed before the page retrieval function, instead of after.
This incorrect sequence triggers a classic use-after-free scenario . During recovery, KVM can remove the root it's using and mark it as invalid. However, because the health check has already run, the system continues to build mappings under a root that is no longer valid. Interestingly, this sorting issue has existed in the code since 2008, but it became critical and exploitable after the release of Linux kernel 5.9 in July 2020 , when a directive was introduced that the system simply stopped enforcing.
Requirements and limitations
For Zapscape to be exploitable, the environment must meet very specific requirements. First, nested virtualization must be enabled in the KVM module, a configuration that allows for a three-tier architecture (L0, L1, and L2). The attacker needs to initiate the attack from the L1 layer , which requires root privileges on that virtual machine. From there, the attacker manipulates memory modes while the activity of the L2 sub-guest forces the L0 host to initiate quota page retrieval, causing memory corruption.
At the hardware level, the conditions vary depending on the manufacturer. On AMD systems that use nested page tables ( SVM ), the vulnerability is more straightforward and doesn't require any additional features. Conversely, on Intel processors, the scenario requires that the L1 guest have exposed four- and five-level EPT pagewalk capabilities . This limits the attack vector on Intel to more recent architectures, specifically from the Ice Lake-SP family onward.
It is worth noting that, although the public proof of concept has managed to escape to the host in controlled environments, security researchers have reported that on certain recompiled kernels the exploit simply crashes the attacker's virtual machine, acting as a denial of service rather than a complete escape.
Mitigation, patches and strategies
The definitive solution to Zapscape arrived in the Linux repositories last July with a patch that corrects the validation order. This fix relocates the stale root check to occur after the MMU page allocation, ensuring that the hypervisor does not create active mappings under a deleted root. These fixes have already been implemented in the stable kernel branches and are being widely distributed by various distributions.
For administrators who cannot upgrade immediately, highly effective temporary mitigations exist. The priority action is to disable nested virtualization on all servers where it is not strictly necessary by passing the `nested=0` parameter to the `kvm_amd` or `kvm_intel` modules in the modprobe configuration files. This measure requires reloading the module, which means stopping any active virtual machines.
Finally, if you are interested in learning more, you can find the details at the following link.