A vulnerability called Zapscape, registered as CVE-2026-64561, was publicly disclosed this week. It is a critical flaw in the Linux KVM hypervisor that allows an attacker to escape from a virtual machine and take full control of the physical host server. If you’re running any KVM-based virtualization — which includes most cloud providers, Proxmox, and many self-hosted setups — this one matters.
The vulnerability has been in the kernel since version 5.9, released in July 2020. It’s been there for six years. The underlying code issue dates back even further, to 2008. But a change in kernel 5.9 made it exploitable, and it wasn’t discovered until now.
What Zapscape Actually Does
KVM (Kernel-based Virtual Machine) is the hypervisor that powers most Linux virtualization. When you run a VM on a Linux server, KVM creates a boundary between the guest (L1) and the host (L0). The guest should never be able to cross that boundary — that’s the entire point of virtualization.
Zapscape breaks that boundary. An attacker who already has kernel-level access inside a guest VM can execute code with root privileges on the host system. From there, they can access every other VM on the machine, steal data, install persistent backdoors, or pivot to other servers on the network.
The vulnerability exists in KVM’s shadow MMU (Memory Management Unit) management code. The shadow MMU handles the translation between virtual and physical memory addresses, and it’s one of the most security-critical parts of any hypervisor. The bug is a classic “use-after-free” — the code checks a status, then uses a memory root that may have already been freed and invalidated. During recovery, KVM can remove the root and mark it as invalid, but since the status check already passed, the system continues building memory mappings under a root that no longer exists.
The ordering problem has existed in the code since 2008, but it only became exploitable after a change in kernel 5.9 introduced a directive that caused the system to stop performing a certain check. Before that change, the bug was present but couldn’t be triggered in a way that led to code execution.
Who Is Affected
Zapscape affects any server running KVM with nested virtualization enabled. This is the critical detail: the vulnerability absolutely requires nested virtualization to be active. If you haven’t enabled it, you’re not vulnerable.
Nested virtualization is the feature that lets you run VMs inside VMs. It’s commonly used in cloud environments where tenants want to run their own virtualization stacks, in development environments for testing, and in some managed Kubernetes setups. Many cloud providers enable it by default because customers expect to be able to use it.
The vulnerability affects both AMD and Intel processors. Intel processors require exposed 4 and 5 level EPT (Extended Page Tables) pagewalk capabilities, which are typically enabled when nested virtualization is active.
If you’re running a bare-metal Linux server with KVM but you’ve never enabled nested virtualization, your servers are not affected. If you’re running a cloud VM (AWS, GCP, Azure), check whether your instance type has nested virtualization enabled — many do by default.
The scope of exposure is significant. KVM is the hypervisor behind Proxmox VE, oVirt, and many enterprise virtualization platforms. Major cloud providers including Google Cloud Platform use KVM as their primary hypervisor. Any organization running KVM-based infrastructure with nested virtualization enabled needs to assess their exposure immediately.
It’s also worth noting that this vulnerability doesn’t require any special network access to exploit. The attacker needs kernel-level privileges inside a guest VM, which means they’ve already compromised the guest. But in multi-tenant environments, that’s not an unreasonable assumption — a vulnerability in any application running in a guest VM could potentially be leveraged to gain kernel access, and from there, the Zapscape exploit gives them the host.
How to Check If You’re Vulnerable
The first step is determining whether nested virtualization is enabled on your server. You can check this with a single command:
cat /sys/module/kvm_intel/parameters/nested
# or for AMD:
cat /sys/module/kvm_amd/parameters/nestedIf the output is Y or 1, nested virtualization is enabled and your server is potentially vulnerable. If it’s N or 0, you’re not affected.
You can also check which kernel version you’re running:
uname -rAny kernel version from 5.9 onward is potentially affected, though the vulnerability requires nested virtualization to be exploitable.
For a more thorough check, you can verify whether the KVM modules are loaded and what options they’re running with:
lsmod | grep kvm
# Should show kvm_intel or kvm_amdIf you’re running a Proxmox VE host, check the datacenter settings to see if nested virtualization is enabled for your nodes. Proxmox enables it by default for new installations, which means many Proxmox servers are potentially exposed.
For organizations managing multiple servers, a simple script can check all hosts at once:
for host in server1 server2 server3; do
echo "=== $host ==="
ssh $host "cat /sys/module/kvm_intel/parameters/nested 2>/dev/null || cat /sys/module/kvm_amd/parameters/nested 2>/dev/null || echo 'KVM not loaded'"
doneThis will tell you at a glance which servers have nested virtualization enabled and need attention.
Immediate Mitigation
The fastest way to protect your servers right now is to disable nested virtualization. This is a temporary measure, but it eliminates the attack vector immediately.
For Intel processors:
echo "options kvm_intel nested=0" | sudo tee /etc/modprobe.d/kvm-intel.conf
sudo modprobe -r kvm_intel
sudo modprobe kvm_intelFor AMD processors:
echo "options kvm_amd nested=0" | sudo tee /etc/modprobe.d/kvm-amd.conf
sudo modprobe -r kvm_amd
sudo modprobe kvm_amdAfter reloading the module, verify that nested virtualization is disabled:
cat /sys/module/kvm_intel/parameters/nested
# Should output N or 0Important: Disabling nested virtualization will break any VMs that rely on nested virtualization. If you’re running VMs inside VMs, those inner VMs will stop working. Check your infrastructure before making this change.
If you can’t disable nested virtualization immediately (because your workloads depend on it), there are additional hardening steps you can take. Restrict which users can create and manage VMs using KVM. Limit the kernel capabilities available inside guest VMs. Apply strict network segmentation between VMs on the same host. None of these fully mitigate Zapscape, but they reduce the attack surface and make exploitation harder.
For Proxmox VE users, you can disable nested virtualization through the GUI or via the command line. The Proxmox wiki has specific instructions for your version, but the basic approach is the same: modify the KVM module options and reload.
Long-Term Fix: Update Your Kernel
The permanent fix is to update to a patched kernel. The vulnerability has been fixed in recent kernel updates, and distributions are pushing patches to their stable branches.
For Ubuntu/Debian:
sudo apt update && sudo apt upgrade linux-image-$(uname -r)For RHEL/CentOS/Fedora:
sudo dnf update kernelAfter updating, reboot the server to load the new kernel:
sudo rebootOnce you’ve confirmed the patched kernel is running, you can re-enable nested virtualization if you need it:
echo "options kvm_intel nested=1" | sudo tee /etc/modprobe.d/kvm-intel.conf
sudo modprobe -r kvm_intel
sudo modprobe kvm_intelWhat This Means for Cloud Providers
If you’re running workloads on major cloud providers, the impact depends on how they handle hypervisor updates. Most cloud providers apply security patches to their hypervisors automatically, but the timeline varies. Some providers patch within hours of a disclosure, others take days or weeks.
For cloud customers, the best approach is to check your provider’s security advisories and patch status. If you’re running your own KVM infrastructure, the mitigation steps above apply directly.
This vulnerability also highlights why nested virtualization should be treated as a security-sensitive feature, not something to enable by default. Every additional layer of abstraction in a virtualization stack creates new attack surfaces. If you don’t need nested virtualization, don’t enable it.
If you’re running a managed Kubernetes cluster on bare-metal servers with KVM, check whether your cluster operator has enabled nested virtualization for any nodes. Some Kubernetes distributions enable it to support certain workloads, and those nodes are potentially exposed.
For organizations running Proxmox VE or similar self-hosted virtualization platforms, this is a good time to audit your node configurations. Check which nodes have nested virtualization enabled, assess whether any of those nodes host untrusted workloads, and apply the mitigation steps if needed.
The Broader Lesson
Zapscape is a reminder that hypervisor vulnerabilities, while rare, can be catastrophic. A VM escape breaks the fundamental isolation guarantee that virtualization provides. For organizations running multi-tenant infrastructure, this is the kind of vulnerability that can expose every customer on a physical server.
The fact that this bug existed for six years before being discovered isn’t unusual — hypervisor code is complex, heavily optimized, and often reviewed less frequently than application code. But it does mean that running unpatched kernels on virtualized infrastructure is a risk that compounds over time.
This vulnerability also underscores the importance of defense in depth. Even if you’re running KVM with nested virtualization enabled, other security measures can reduce your risk. Keeping guests patched and hardened limits the attacker’s ability to gain kernel-level access in the first place. Network segmentation between VMs limits lateral movement. Monitoring for unusual hypervisor activity can catch exploitation attempts before they succeed.
The KVM development team has responded quickly to this disclosure, and patches are already available in recent kernel updates. But patches only help if you apply them. For server administrators, this means establishing a regular kernel update cycle, testing patches in staging environments, and deploying them to production as quickly as your change management process allows.
Update your kernels now. Disable nested virtualization if you don’t need it. And keep an eye on security advisories — the next hypervisor vulnerability is probably already in the code, waiting to be found.
