Zapscape — KVM guest-to-host escape

This tracker is no longer updated. Every tracked distribution has shipped a kernel carrying the 2abd5287f083 backport for each release it still supports. The rows left vulnerable will not flip: the upstream 5.10.y LTS line had no backport when tracking ended, and Debian 11 (bullseye) left Debian LTS on 2026-08-31 without one. The in-window lines that ended without the fix (upstream 7.0.y and the superseded Proxmox series) likewise remain permanently vulnerable, as noted in the sections below.

Summary

How the exploitation chain works

Zapscape is a memory-corruption bug in KVM’s shadow MMU — the software page-table walker KVM uses when hardware two-dimensional paging (Intel EPT / AMD NPT) is not in play for a mapping, most notably for nested guests. The flaw is one of ordering: both x86 shadow-MMU page-fault handlers checked whether a fault had gone stale before making shadow pages available, when the check has to come after.

When a page fault is taken, direct_page_fault() (and its paging-mode twin FNAME(page_fault)) take mmu_lock and then, in the vulnerable order, first call is_page_fault_stale() — bailing with RET_PF_RETRY if the vCPU’s root has become invalid or obsolete since the fault was recorded — and only then call make_mmu_pages_available(), which reclaims shadow pages when the MMU is at its cap. The problem is that reclamation (kvm_mmu_zap_oldest_mmu_pages()) can zap the vCPU’s own, in-use root, marking it invalid. Because the stale check already ran and passed, the handler proceeds to map memory into a root that is now invalid.

Populating an invalid root would be harmless on its own, but child shadow pages inherit their parent’s role — including role.invalid. Any children created during the map/fetch are therefore created as invalid pages and linked onto the list of active MMU pages, violating the invariant (established by f95eec9bed76 in Linux 5.9) that invalid shadow pages are never on the active list. That corrupts KVM’s shadow-page bookkeeping into a use-after-free the PoC drives to host code execution. The fix simply moves the stale-root check to after make_mmu_pages_available(), so a root zapped during reclamation is seen as stale and the fault retried instead of populated.

ℹ️ The vulnerable path is the shadow MMU, which on modern EPT/NPT hardware is exercised chiefly through nested virtualization. Disabling nested virt (kvm_intel.nested=0 / kvm_amd.nested=0) removes the guest-driven path for untrusted guests. Two ways in exist: a hostile guest escaping to host root, and — where /dev/kvm is world-readable/writable (the default on EL8 and later) — an unprivileged local user reaching the same code directly. Restricting /dev/kvm closes the second without touching the first. The nested-virt path also depends on the host CPU: AMD hosts (SVM/NPT) are reachable unconditionally, while Intel hosts (VMX/EPT) are reachable only where the CPU exposes 5-level EPT to guests — Ice Lake-SP and newer — so older Intel hosts are not reachable through the disclosed path. Only a patched kernel removes the flaw — disabling nested virt or restricting /dev/kvm narrows who can reach an unpatched kernel but does not fix it.

Vulnerable commit range

The reachable lifetime is therefore v5.9 (2020) through v7.1; the fix is in mainline ≥ 7.2-rc5 and the 5.15 / 6.1 / 6.6 / 6.12 / 6.18 / 7.1 stable backports. ARM64 KVM uses a different MMU and is not affected by this bug — see ITScape for that researcher’s arm64 escape.

Patch status

What decides exposure is whether the kernel carries the 2abd5287f083 backport. Because the bug dates to v5.9, every kernel below is inside the affected window and stays vulnerable until it ships the fix. /dev/kvm exposure and nested-virt defaults change who can reach the bug, not whether the kernel is fixed.

Unusually for this family, the fix reached the 6.6, 6.12, 6.18, and 7.1 stable lines first (all on 2026-08-03); 6.1 picked it up on 2026-08-19, and 5.15 on 2026-08-27. The 5.10 LTS line had no fix when this tracker was archived (2026-09-15), so the distributions still riding it are vulnerable with nothing upstream to adopt. The first group tracks the upstream kernel itself; the rest are a focused set of x86-64 distributions (other systems named in the disclosures appear only in prose). Current kernel is the latest version observed in the row’s user-facing channel; First fixed is the first release or build carrying the fix, and Fixed since the date it first held (both stay — while a row is vulnerable).

Linux kernel

The fix reached mainline in v7.2-rc5 and was backported to the 7.1, 6.18, 6.12, 6.6, 6.1 and 5.15 lines.

• 7.0.y reached end of life at 7.0.14 (2026-06-27) without the backport. A host still on it stays vulnerable — move to a maintained line.
• 7.1.y is end of life at 7.1.13. It carries the fix, but gets no further updates.
• 5.10.y had no fix when this tracker was archived. It predates is_page_fault_stale() and has the stale-root check in an older shape, so a fix there needs adapting rather than a straight backport.

To check a tree directly: the reordered calls are in direct_page_fault() in arch/x86/kvm/mmu/mmu.c and FNAME(page_fault) in arch/x86/kvm/mmu/paging_tmpl.h; the fix moves is_page_fault_stale() to after make_mmu_pages_available().

Debian

Every Debian suite’s linux is in-window, since the bug predates them all. bookworm’s opt-in 6.12 kernel is the separate linux-6.12 source package in bookworm-security.

bullseye (Debian 11) left LTS support on 2026-08-31. Its 5.10 default and its opt-in linux-6.1 package get no further Debian security updates, and neither carries the fix. Upgrade to a supported release. Freexian’s commercial Extended LTS covers Debian 11 through 2031 per package; check with Freexian whether its kernel carries the fix.

Debian keeps /dev/kvm owned root:kvm, mode 0660, so the local vector needs kvm-group membership there. The guest-escape vector is unaffected by that.

Proxmox VE

Proxmox ships its own kernels (proxmox-kernel-*), so Debian’s status does not carry over. PVE 9’s default proxmox-kernel-7.0 and PVE 8’s default proxmox-kernel-6.8 carry a cherry-pick of 2abd5287f083. Proxmox issues no numbered advisories; the kernel changelogs and the support-forum threads are the public record.

Superseded series never got the fix: PVE 9’s 6.17 and 6.14, and PVE 8’s opt-in 6.14 and old 6.11. They are no longer updated, so a host booted into one stays vulnerable — boot the release’s default kernel.

NixOS

Every NixOS channel and branch in the table defaults to linux_6_18 (linuxPackages), which carries the fix, and the linuxPackages_latest alias points at the fixed linux_7_2.

Kernel updates land on nixpkgs master first and reach each channel once its Hydra jobset passes, so a channel can sit a few days behind master. The -small channels (nixos-unstable-small, nixos-26.05-small) run a reduced jobset and pick up kernel updates fastest.

Which ref a flake input follows:

• github:NixOS/nixpkgs/nixos-unstable and github:NixOS/nixpkgs/nixos-26.05 follow those channels — the GitHub channel branches are updated to exactly the published channel pins.
• A bare github:NixOS/nixpkgs with no ref follows master, and github:NixOS/nixpkgs/release-26.05 follows that branch. Both are ungated development branches — they carry a kernel bump as soon as it lands, often a day or more before a channel publishes it.
• A bare nixpkgs registry input resolves by default to the nixpkgs-unstable channel: a separate channel aimed at Nix on other operating systems, not gated on the NixOS tests.

Rocky Linux / RHEL family

The EL family ships /dev/kvm world-accessible (EL8 and later), so on those hosts any local user, not just a guest, can reach the bug. With the guest-escape path, this is the highest-exposure case.

RHEL 6 and 7 are not affected: they predate the v5.9 invariant the bug breaks. Red Hat advisories for extended-support streams, beyond the current minor releases in the table:

• RHEL 10: 10.0 E2S RHSA-2026:49030.
• RHEL 9: 9.6 EUS RHSA-2026:49031; 9.4 E4S RHSA-2026:48386.
• RHEL 8: 8.8 TUS/E4S RHSA-2026:47869.

On RHEL 9 and 10 the real-time kernel-rt is fixed by the same advisories as the kernel; RHEL 8.10’s has its own, RHSA-2026:45116.

AlmaLinux, CloudLinux and Oracle Linux’s Red Hat Compatible Kernel rebuild RHEL’s kernel, so they get the fix as they rebuild Red Hat’s advisories.

CloudLinux also patches its own .lve kernels. Per its advisory, CloudLinux 9 ships a fixed kernel-5.14.0-687.30.1.el9_8 or newer, CloudLinux 7h and 8 have kernel-4.18.0-553.150.1.lve or newer in testing, and CloudLinux 8 LTS / 9 LTS / 10 are in preparation. Its Ubuntu 22.04 kernel comes via Canonical, with a KernelCare livepatch in preparation.

Amazon Linux

The three AL2023 streams are the default kernel package (6.1 line) and the opt-in kernel6.12 and kernel6.18 packages. Each was fixed by an Amazon cherry-pick into a build below its line’s upstream first fix, so judge an AL2023 kernel by its ALAS, not its version number.

Amazon Linux 2 reached end of support on 2026-06-30 with no ALAS for this CVE. Its 5.10 and 5.15 amazon-linux-extras kernels stay vulnerable (the 4.14 default predates the bug) — migrate to AL2023.

Detection

Is the running kernel in the affected window and missing the fix? Compare the running kernel against the Patch status table above — the Linux kernel rows for the upstream point releases, and your distribution’s row:

uname -r

Is this an x86 host? Zapscape is x86-only (Intel or AMD); arm64 hosts are not affected by this bug:

uname -m

Is KVM in use, and is nested virtualization enabled? The shadow-MMU path is reached chiefly through nested guests; Y means nested virt is on:

cat /sys/module/kvm_intel/parameters/nested

On AMD hosts check the AMD module instead:

cat /sys/module/kvm_amd/parameters/nested

On an Intel host, is the CPU new enough to be reachable? The disclosed path needs the host to expose 5-level EPT to guests (Ice Lake-SP and newer). Empty output means the CPU predates that and the disclosed path is not reachable; AMD hosts print no such line and are reachable regardless:

grep -ow ept_5level /proc/cpuinfo

Who can open /dev/kvm? World access (e.g. crw-rw-rw-, the EL8+ default) exposes the local unprivileged vector; crw-rw---- root:kvm limits it to the kvm group:

ls -l /dev/kvm

Public PoC

The upstream PoC is in V4bel/Zapscape. CloudLinux reports that the published exploit does not run against its CloudLinux-built kernels as written — in their reproduction it crashed the attacker’s own guest rather than escaping — but on an unpatched host the flaw is a host-compromise primitive. Do not run it on a system you are not authorised to test.

Mitigation

The real fix is a patched kernel (the 2abd5287f083 backport). Until one is installed, the exposure can be narrowed.

Unload KVM where virtualization is not used (removes the bug entirely)

On a host that runs no VMs, unload and blacklist the KVM modules so the vulnerable code cannot be reached at all (no reboot needed):

sudo modprobe -r kvm_intel kvm

echo -e 'install kvm /bin/false\nblacklist kvm_intel\nblacklist kvm_amd' | sudo tee /etc/modprobe.d/disable-kvm.conf

Use kvm_amd in the first command on an AMD host. This is CloudLinux’s recommended measure for non-virtualization hosts.

Disable nested virtualization (removes the guest-driven path)

On a host that does run VMs but not nested ones, turn nested virt off and reload the module (no running nested guests):

sudo modprobe -r kvm_intel

echo 'options kvm_intel nested=0' | sudo tee /etc/modprobe.d/99-zapscape.conf

On an AMD host use kvm_amd in both commands. This blocks the shadow-MMU path for untrusted guests but does not close the hole for a workload that legitimately needs nested virtualization.

Restrict /dev/kvm (removes the unprivileged local vector)

Where /dev/kvm is world-accessible (EL8+), restrict it to a trusted group so unprivileged local users cannot open it directly:

sudo chmod 0660 /dev/kvm

Persist it with a udev rule:

echo 'KERNEL=="kvm", GROUP="kvm", MODE="0660"' | sudo tee /etc/udev/rules.d/65-kvm.rules

This does not stop a hostile guest escaping — it only removes the local unprivileged path. None of these measures is a fix; the kernel hole remains until patched.

Risk notes

• Multi-tenant / untrusted-guest hosts: this is a guest-to-host-root primitive from inside an otherwise isolated VM — the headline risk for anyone running untrusted guests with nested virtualization enabled.
• EL8+ hosts (/dev/kvm world-accessible): any unprivileged local user can reach the bug directly, without needing a guest — self-hosted CI and shared multi-user hosts are directly in scope. RHEL/Rocky 8, 9, and 10 now all have a vendor fix.
• AMD unconditional; Intel only Ice Lake-SP and newer: demonstrated on both vendors, so there is no blanket “AMD is safe” caveat — AMD hosts are reachable whenever nested virt is on. On Intel the disclosed path needs 5-level EPT exposed to guests, so pre–Ice Lake-SP hosts are not reachable through it; treat that as a scoping aid, not a substitute for patching a host that runs untrusted guests.
• Backports are narrow (CVE-2026-64561): the fix has landed in 7.1.6, 6.18.42, 6.12.101, 6.6.148, 6.1.183 (2026-08-19), and 5.15.218 (2026-08-27), but the 5.10.y LTS line had none when this tracker was archived (2026-09-15). Debian has backported it into bookworm’s 6.1.y default (6.1.187-1); bullseye’s LTS window closed on 2026-08-31 with neither its 5.10.y default nor its opt-in linux-6.1 package ever picking up a fix, so both are permanently vulnerable under standard support. Amazon has cherry-picked the fix independently, below the upstream threshold, into all three currently supported AL2023 kernel streams: the default kernel (ALAS2023-2026-2058), the kernel6.12 opt-in (ALAS2023-2026-2057), and the kernel6.18 opt-in (ALAS2023-2026-2071). Check the distribution row for your kernel.

Verification log

Every verdict in the table above is backed by a checkable source. This log records the provenance — the advisory, repository index, or git reference that established each fact — so any row can be audited or reproduced. Most readers never need it.

References