A newly disclosed vulnerability in KVM/x86, tracked as CVE-2026-64561 and nicknamed Zapscape, is another reminder of why keeping hypervisors fully patched is critical in Linux virtualization environments. While many reports have quickly linked it to Proxmox VE, the vulnerability is not a Proxmox-specific issue. Instead, it resides in Kernel-based Virtual Machine (KVM), the Linux kernel hypervisor used by Proxmox VE, OpenStack, oVirt, and many public and private cloud platforms.
Zapscape in 30 seconds
- CVE-2026-64561 affects the KVM/x86 subsystem in the Linux kernel.
- It could allow a guest-to-host escape through a flaw in the Shadow MMU.
- Exploitation requires elevated privileges inside the guest and, in many scenarios, nested virtualization.
- The vulnerability is not in QEMU or Proxmox VE itself, but in the Linux kernel.
- Administrators should deploy patched kernels as soon as updates become available for their distribution.
Over the past few months, KVM has received increased attention from security researchers. Following Januscape (CVE-2026-53359) comes Zapscape, a separate vulnerability affecting the same Shadow MMU component, one of the most complex parts of Linux virtualization.
A flaw in KVM’s Shadow MMU
According to researcher Hyunwoo Kim (@v4bel), Zapscape is a Use-After-Free (UAF) vulnerability triggered during Shadow MMU page reclamation.
During certain recursive cleanup operations, KVM frees a shadow root page that is still referenced by the hypervisor. It then continues operating on that invalid memory structure, potentially allowing corruption of kernel memory on the host.
The impact can be severe: under the right conditions, a malicious virtual machine could execute code with kernel privileges on the physical host.
This is not just a Proxmox VE issue
One misconception already appearing across headlines is that Zapscape is a Proxmox vulnerability.
It is not.
Any virtualization platform relying on a vulnerable KVM/x86 implementation may be affected, regardless of the management layer sitting on top.
Potentially affected environments include:
- Proxmox VE
- OpenStack
- libvirt-based private clouds
- Custom KVM virtualization platforms
- Public cloud providers using KVM as their hypervisor
Since the flaw resides in the Linux kernel, upgrading Proxmox VE alone does not eliminate the risk if the underlying kernel remains vulnerable.
Is it easy to exploit?
In short, no.
Although the potential impact is high, successful exploitation depends on several specific conditions.
Conditions described by the researcher
| Requirement | Needed |
|---|---|
| Vulnerable KVM host | ✅ |
| Root privileges inside the guest | ✅ |
| Nested virtualization enabled | Usually yes |
| x86 architecture | ✅ |
| Vulnerable Shadow MMU configuration | ✅ |
This means many traditional enterprise virtualization environments face a lower risk than large multi-tenant cloud providers where customers fully control their own virtual machines.
Public cloud environments face the highest exposure
In public cloud infrastructures, customers typically have root access inside their own virtual machines.
If nested virtualization is also available, Zapscape could potentially be leveraged to compromise the underlying physical host.
According to the technical documentation published by the researcher, a successful attack could allow an attacker to:
- execute arbitrary code as root on the host;
- crash the host kernel (Denial of Service);
- compromise other virtual machines running on the same physical server.
For this reason, vulnerabilities of this type are generally treated with the highest priority by cloud providers.
A proof of concept is already public
Following the coordinated disclosure period with Linux kernel maintainers, the researcher has published both the technical analysis and a proof of concept (PoC).
The PoC is not a weaponized exploit designed for immediate use against commercial cloud providers. Instead, it demonstrates the complete exploitation chain using QEMU TCG in a controlled environment.
However, the researcher also notes that adapting the exploit to other environments should not be particularly difficult.
Affected versions
Zapscape affects code introduced between the following Linux kernel commits:
- f95eec9bed76 (July 8, 2020)
- 2abd5287f083 (July 21, 2026)
As a result, numerous Linux kernel versions may remain vulnerable until patched releases are installed.
Best practices for system administrators
While Linux distributions continue rolling out fixes, administrators should pay particular attention to virtualization hosts running workloads from third parties or untrusted users.
Recommended actions include:
- Deploy patched kernels as soon as they become available.
- Disable nested virtualization wherever it is not required.
- Restrict access to /dev/kvm.
- Monitor security advisories from your Linux distribution.
- Maintain a regular patching strategy for virtualization hosts.
Zapscape also reinforces an important lesson: keeping Proxmox VE updated is not always enough. Some of the most critical virtualization vulnerabilities originate in the Linux kernel itself, making timely kernel updates just as important as maintaining the virtualization platform.
Frequently Asked Questions
Is Zapscape a Proxmox VE vulnerability?
No. The vulnerability exists in KVM/x86, the Linux kernel hypervisor used by Proxmox VE and many other virtualization platforms.
Is QEMU affected?
No. According to the researcher, the flaw resides in KVM and can be triggered independently of the emulator being used.
Does the attacker need root privileges inside the virtual machine?
Yes. The documented exploitation technique requires elevated privileges within the guest operating system.
What should system administrators do?
Install patched kernels as soon as they become available, review whether nested virtualization is enabled, and follow the security guidance provided by both their Linux distribution and the Proxmox project.
Sources: