A new critical vulnerability discovered in the Linux kernel’s KVM/x86 subsystem once again highlights the importance of security in hypervisors based on this technology, including Proxmox VE, as well as other platforms that use KVM as their virtualization component. Identified as CVE-2026-64561 and named Zapscape, this flaw allows, under certain conditions, a virtual machine to escape to the host and execute code with kernel privileges.
Key points about Zapscape in 20 seconds
- The vulnerability CVE-2026-64561 affects the Linux kernel’s KVM/x86 subsystem.
- It enables a possible virtual machine escape to the host through a flaw in Shadow MMU.
- Exploitation is only possible if the guest has elevated privileges and nested virtualization is enabled.
- Proxmox VE and any platform based on KVM should apply kernel updates as they become available.
The flaw was uncovered by researcher Hyunwoo Kim (@v4bel), who published both a technical analysis and a proof of concept (PoC) after the embargo period, coordinated with Linux kernel maintainers.
The issue is in KVM, not in Proxmox VE
While the news has caused concern among Proxmox VE administrators, it is important to clarify: the vulnerability does not reside in Proxmox, but in KVM (Kernel-based Virtual Machine), the hypervisor integrated into the Linux kernel used by many virtualization platforms.
This means that the scope extends far beyond Proxmox VE. It can also affect:
- Custom KVM infrastructures.
- Cloud platforms based on KVM.
- Solutions that use KVM as their virtualization engine.
- Linux distributions exposing KVM to external users or providers.
The researcher explains that the flaw occurs within the Shadow MMU of KVM/x86 during memory page recovery when nested virtualization is involved.
What exactly is Zapscape?
According to the technical documentation published by the researcher, Zapscape is a Use-After-Free (UAF) vulnerability.
During certain Shadow MMU page recovery operations, KVM recursively deletes a root page that is still in use. It then continues to operate on a now-freed structure, leading to kernel memory corruption on the host.
If the attack is successful, an attacker could execute code with root privileges on the host system.
What impact could this have?
The technical report outlines two main scenarios.
Escape from a virtual machine
This is the most concerning scenario for cloud providers.
A client controlling their virtual machine could compromise the physical server hosting it and potentially affect other virtual machines on the same host.
Potential consequences include:
- Remote code execution on the host;
- Denial of Service (DoS);
- Compromise of other virtual machines.
Local privilege escalation
In certain Linux distributions where /dev/kvm allows access without elevated privileges, the flaw could also be exploited as a local escalation vulnerability to gain administrator permissions.
Not all Proxmox installations are exposed
It is important to emphasize that the presence of the vulnerability does not automatically mean every installation is exploitable.
According to the researcher, multiple conditions are required to reproduce the attack:
| Requirement | Necessary? |
|---|---|
| Vulnerable KVM/x86 | Yes |
| Nested virtualization | Yes |
| Root privileges inside the VM | Yes |
| Specific Shadow MMU configuration | Yes |
In other words, a home or business setup that does not permit nested virtualization for untrusted users faces a very different risk profile compared to a multi-tenant cloud provider.
Affected versions
The researcher indicates that the vulnerability affects code introduced in the following Linux kernel commits:
- From f95eec9bed76 (July 8, 2020).
- Up to 2abd5287f083 (July 21, 2026).
This places the origin of the problem around six years ago, with multiple kernel versions impacted until it was patched.
QEMU is not the issue
Another key point clarified in the documentation is that QEMU is not affected by this vulnerability.
The flaw is entirely within KVM inside the Linux kernel, so it can manifest independently of the virtualization software used by the administrator.
This also means that any platform using KVM as the backend must apply future kernel updates, regardless of the QEMU version installed.
What Proxmox VE administrators should do
While different distributions release updates, the main recommended actions are to follow standard security best practices:
- Apply kernel updates as soon as they are available;
- Avoid enabling nested virtualization unless strictly necessary;
- Restrict access to /dev/kvm to authorized users;
- Review guidance provided by Proxmox and the Linux distribution in use.
As with most KVM vulnerabilities, the risk largely depends on the threat model. Multi-tenant cloud environments running untrusted client VMs are where such issues are most critical.
A new warning for cloud operators
Zapscape arrives just months after Januscape (CVE-2026-53359), another vulnerability found in the same Shadow MMU subsystem of KVM. While the researcher clarifies these issues have different causes, he emphasizes that such errors highlight the need for sustainable update processes in hypervisors.
The release of a functional proof of concept increases urgency for administrators and cloud providers to deploy patches once available.
Frequently Asked Questions
Does the vulnerability directly affect Proxmox VE?
No. The flaw resides in KVM/x86, the hypervisor embedded in the Linux kernel used by Proxmox VE and many other virtualization platforms.
Can an escape from a virtual machine to the physical server occur?
Yes, according to the researcher, under certain conditions, the vulnerability can enable a compromised virtual machine with elevated privileges to attack the host.
Is QEMU also vulnerable?
No. The published documentation indicates the problem lies within KVM in the Linux kernel, not in QEMU.
What should administrators do?
Update the kernel when patches are available, limit nested virtualization to only trusted scenarios, and follow security recommendations from your distribution and hypervisor provider.
