Zapscape CVE-2026-64561: a nested VM could escape to its KVM host

Zapscape, tracked as CVE-2026-64561, is a use-after-free vulnerability in the KVM/x86 shadow MMU. Privileged code in an L1 guest with nested virtualisation enabled could cause the host kernel to use a freed page-table structure. Researchers demonstrated a path from guest-side actions to root code execution on the host.

This is a critical boundary for clouds and labs that deliberately expose VMX or SVM capabilities to tenants. Root inside a rented VM is a normal customer permission, not evidence of a previous hypervisor compromise. Security must assume that a privileged guest is hostile.

What breaks in the shadow MMU

KVM maintains structures that map a guest’s view of memory onto host physical memory. With nested virtualisation, L1 runs its own L2 machines and the host has to emulate another translation layer. Shadow pages are removed — “zapped” — when mappings become invalid or KVM reclaims its MMU page quota.

In the vulnerable path, recursive zapping could free a root shadow page that remained in use while a page fault was handled. Later operations followed a stale pointer. A use-after-free in the host kernel enables controlled memory corruption and can break the guest–host boundary.

The CVE-2026-64561 record and Linux stable-tree fixes identify affected builds. Practical exploitation requires nested-virtualisation access and privileged code in L1. Hosts that never expose these features to untrusted VMs have a much smaller surface for this scenario.

Finding exposure

Determine not only whether the KVM module has nested=1, but also whether specific instance classes receive the feature. Inspect libvirt templates, cloud profiles, Kubernetes virtualisation, training platforms, build services and environments running Android emulators.

Nested virtualisation is often enabled for a short test and then remains in an image or policy. A host-level inventory that is not connected to guest configuration can therefore create false confidence.

Response and hardening

1. Install a kernel containing the CVE-2026-64561 fix and reboot the host so the new code is actually active.
2. Disable nested virtualisation for tenants that do not need it and remove vmx or svm from their virtual CPU definitions.
3. Evacuate untrusted VMs from unpatched hosts and do not restart them until the running kernel is verified.
4. Separate host pools that offer nested virtualisation from ordinary workloads and high-value data.
5. Monitor VM-definition changes, CPU-flag exposure, unusual guest restarts and KVM or MMU errors in kernel logs.
6. Restrict /dev/kvm access in containers and runners; exposing the device may create another guest layer.
7. After suspected escape, treat the complete host and shared secrets as potentially compromised, not only one VM.

Verifying the state of a KVM fleet

A CMDB should retain three separate facts: installed kernel package, kernel actually running and nested-virtualisation exposure for each VM. Only their intersection answers whether a workload could reach the vulnerable path. Live migration requires checking both source and destination because an unpatched node can reintroduce risk after another part of the cluster was correctly rebooted.

KVM messages, Oops reports and MMU traces should be retained outside the host. A sudden qemu crash, shadow-page accounting error or unusual sequence of L2 creation may guide an investigation but is not proof of exploitation by itself. For high-risk pools, measured boot and kernel-version attestation can be required before accepting an untrusted VM. The scheduler then makes its decision from running-host state rather than an image declaration.

Facts and analysis

Sources confirm the use-after-free, nested-virtualisation prerequisite and kernel fix. A public demonstration establishes possible impact but does not prove active exploitation across KVM fleets. Separate host pools are Breachroad’s architectural conclusion.

A cloud security assessment can connect host versions with the VM flags actually exposed. Technical security training helps platform teams rehearse a response to vulnerabilities that cross virtualisation boundaries.