Zapscape (CVE-2026-64561): VM escape from a virtual machine to the host kernel — what should the hypervisor owner do?

TrustMe · August 7, 2026, 9:19am

On August 4, the NVD database added an entry CVE-2026-64561, and on August 6 a researcher published an analysis and a proof-of-concept under the name Zapscape. The gist in one line: a guest with root privileges inside a virtual machine, under certain conditions, can execute code in the host kernel or crash it entirely — along with all neighboring VMs.

Below is an analysis in the format “question — answer.” The questions are the ones admins actually ask, not the ones that look good in a press release.

What exactly broke?

Official wording from the kernel changelog reads: «KVM: x86: Check for invalid/obsolete root after making MMU pages available». In plain terms: in the shadow MMU (shadow MMU) of the KVM/x86 subsystem, the order of two checks was swapped.

When KVM runs out of pages for shadow tables, it triggers reclaim — freeing pages. This process can mark the current root directory of the page table as invalid. The problem is that the check “is the root still alive?” was executed before reclaim, not after. As a result, KVM continued to operate with an already freed root and could write to freed memory — a classic use-after-free.

The internal invariant was also violated: an invalid page should not end up in the active list, yet child shadow pages were calmly attached to it.

Info:

The bug lived in the kernel from the commit f95eec9bed76 of July 8, 2020, i.e. since around Linux 5.9. It was fixed by the commit 2abd5287f083, merged upstream on July 21, 2026. Five years of quiet life — a typical biography for an MMU bug.

How scary is it in numbers?

Red Hat’s preliminary assessment rated CVSS 3.1 = 7.0 and classified it as Important, CWE-825 (Expired Pointer Dereference). NVD hadn’t assigned its own score at the time of writing this note — in the CVE card all three CVSS fields are empty.

So 7.0 is the assessment of one vendor, not a consensus. But the practical impact is described in the researcher’s publication: a DoS on the entire physical server or code execution with root privileges on the host.

Does this affect me? Trigger conditions

Here lies the key difference that sets Zapscape apart from “yet another kernel CVE.” The attack requires nested virtualization: the attacker needs root-level inside the guest VM (L1) to start another VM inside it (L2) and through it reach the host’s shadow MMU.

Then architectural nuances come into play:

AMD (SVM/NPT) — straightforward path, no additional conditions.
Intel (EPT) — the guest L1 must be granted both page-walking lengths, 4-level and 5-level. This significantly narrows the surface: five-level pages correspond to Ice Lake-SP and newer.

Warning:

Separately, a parallel track is machines where /dev/kvm is world-writable (permissions 0666). There it works not as guest escape but as local privilege escalation: any user on the host can reach the kernel. Check: ls -l /dev/kvm.

How to quickly check if nested virtualization is enabled on my hosts?

# Intel
cat /sys/module/kvm_intel/parameters/nested
# AMD
cat /sys/module/kvm_amd/parameters/nested
# Y or 1 — nesting is enabled

An important nuance: module-level permission does not necessarily mean the guest actually received it. The guest needs the vmx (Intel) or svm (AMD) flag in its virtual CPU. In Proxmox this happens when the processor type is set to host or the flag is explicitly added. Check from inside the guest:

grep -oE '(vmx|svm)' /proc/cpuinfo | sort -u

If nothing is shown — nesting isn’t exposed to this VM, and the L1 → L2 vector is closed.

Which kernels are already fixed?

According to NVD, the fix made it into the stable branches 6.6.148, 6.12.101, 6.18.42, 7.1.6 and in 7.2-rc5. The LTS kernel releases 6.18.42 / 6.12.101 / 6.6.148 are independently confirmed in stable branch announcements.

For distributions: according to TuxCare, RHEL 8 is fixed starting with 4.18.0-553.147.1.el8_10 (July 23), RHEL 9 — with 5.14.0-687.30.1.el9_8 (July 22).

For Proxmox: in an official forum, a company employee named the patched builds — proxmox-kernel-6.8.12-40-pve and kernel 7.0.14-9 — and confirmed that the packages are available in pve-no-subscription.

Success:

Action steps for the hypervisor owner:

uname -r — compare with the above numbers.
apt update && apt full-upgrade (or dnf update), then a reboot: the kernel isn’t hot-swapped on the fly unless you have live-patching.
On Proxmox — pveversion -v and verify that the new kernel loaded, not the old one from the first boot position.
ls -l /dev/kvm — permissions should be 660 root:kvm, not 666.

What if you can’t update right now?

The simplest temporary workaround is to remove the trigger condition, i.e. disable nested virtualization:

# /etc/modprobe.d/kvm-nested.conf
options kvm_intel nested=0
# or
options kvm_amd nested=0

Then update-initramfs -u and reboot (or unload/load the module if no VM is running).

Error:

Do not regard disabling nesting as a substitute for the update. This removes one condition of operation, not the use-after-free issue. The second path — via an open /dev/kvm — does not close this at all.

Side effects are honest: nested hypervisors, Docker Desktop and WSL2 inside VMs will stop working, Android emulators with hardware acceleration, and any test rigs like “Proxmox inside Proxmox.” For most home labs it’s tolerable for a few days, for CI farms — not.

Is there any exploitation in the wild?

As of the publication time, confirmed cases hadn’t been reported. The PoC is published, but, according to the researcher, it requires adaptation to a specific target — it’s not a matter of “download and run.”

Important:

Practical takeaway: no need for panic, but waiting for the next maintenance window is a bad choice if you are renting out compute to others. Risk formula is simple: someone else’s root inside your VM + nested access given to them = patch today. All VMs are yours and nesting isn’t used — patch in a planned manner.

What does this say about renting VPS in general

A useful reminder for those who rent: VM isolation is a guarantee that rests on the hypervisor code, and it’s as mortal as everything else. You don’t get to choose or inspect your neighbor’s hardware.

From this follow two practical implications. First: what must never leak — keys, backups, and databases with personal data — should be kept on encrypted volumes that aren’t mounted constantly, so a memory dump gives an attacker less to work with. Second: ask your hoster about kernel update policy. A provider that reboots hypervisors once every few months is a separate class of risk, not reflected in price.

Sources

Question:

Have you disabled nested virtualization on your hosts — and what stopped working as a result? And a separate question for those who rent VPS: does your hoster notify about hypervisor reboots for kernel patches, or do you learn about it from the uptime schedule?