Zapscape (CVE-2026-64561): KVM Guest-to-Host Escape for Proxmox Operators

TL;DR

Zapscape is a use-after-free in the Linux KVM x86 shadow MMU that lets a guest with kernel privileges, on a host that exposes nested virtualization, corrupt host kernel memory and follow a documented path to host root.[1][3] The part that should move your week: this is the second flaw in the same shadow-MMU code in a month. If you rebooted a node to patch Januscape (CVE-2026-53359) in late July, that reboot did not necessarily cover Zapscape, because the two are separate bugs with separate fixes and separate kernel bumps.[18][1] Check the running kernel on every node, not just whether you "patched KVM" at some point this month. The public proof-of-concept reaches a real host file write on AMD, but it is configuration-locked demo code, and independent vendor testing reproduced only a guest crash, so treat it as a credible escape path that is not yet fleet-demonstrated and patch on schedule anyway.[1][7][8]

What is Zapscape

Zapscape (CVE-2026-64561) is a stale-root ordering bug in the KVM x86 shadow MMU. The name comes from the finder, Hyunwoo Kim (@v4bel). The Hacker News covered the disclosure when it went public on 2026-08-06.[6] Kim's public release on GitHub carries the full write-up and the proof-of-concept.[1][22] When a guest runs a nested guest (L2), KVM builds shadow page tables to translate addresses, because one hardware stage, EPT on Intel or NPT on AMD, cannot cover both the L1 and L2 page tables at once.[1] KVM holds an invariant that invalid shadow pages are never on the list of active MMU pages.[4][1]

The bug is an ordering error. In the vulnerable kernels, both page-fault paths run the stale-root check before the quota reclaim step. The check looks at the root as it was when the fault started, then make_mmu_pages_available() runs and, under free-page pressure, can reclaim and invalidate that very root, and the path then maps memory into the now-invalid root without checking again.[1][2] The fix, commit 2abd5287f083, moves the stale-root check to after the reclaim in both fault paths, direct_page_fault() in mmu.c and FNAME(page_fault) in paging_tmpl.h, so the fault retries whenever reclaim invalidated the root.[2]

That ordering flaw has been in the tree since 2020. The commit message says the tracking logic existed since 2008, but the version that made it exploitable landed with Linux 5.9, commit f95eec9bed76, which introduced the invariant that invalid shadow pages cannot sit on the active list.[1][5] So any kernel from 5.9 forward that has not picked up the fix is in the vulnerable window, which is effectively most of the modern kernels still shipping in homelab and cloud images today.[3][1]

The exploit setup aliases one shadow-page header to be both a child of a nested page table and the root of another. When the parent entry is removed, the recursive reclaim path grabs it despite its root reference, pulls it off the active list, and marks it invalid. Children created during the following map inherit the invalid role and get inserted onto the active list anyway, which is the double-attach plus free that produces the use-after-free.[1][2]

Technical analysis

The upstream fix, verified

The fix is small and mechanical. Commit 2abd5287f083 ("KVM: x86: Check for invalid/obsolete root after making MMU pages available") touches two files with the identical reorder in both: the is_page_fault_stale() test is moved from before to after make_mmu_pages_available(), and the fault is restarted with RET_PF_RETRY when the root was invalidated in the meantime.[2] It was posted to the kernel mailing list and merged to mainline on 2026-07-21, well before the public disclosure.[1][2]

The backport landed in the stable branches 6.6.148, 6.12.101, 6.18.42, 7.1.6, and 7.2-rc5.[3]

Intel vs AMD: the preconditions are different

This is the part that trips up the coverage, because Intel and AMD do not reach the bug the same way. Do not read the Intel requirement onto AMD or vice versa.

The practical consequence: an AMD host that allows nesting is reachable without any special CPU capability being passed to the guest, whereas an Intel host needs the walk-length-4 and walk-length-5 EPT bits both exposed to L1.[8][1] On my own AMD node that means the precondition is weaker than the Intel coverage implies, which is why I treat the AMD case as the one to take seriously.

What the PoC does, and what it has not done

The researcher's PoC runs as an unprivileged process that acts as its own VMM. It uses guest_memfd and /dev/kvm, builds a 518 MiB, 2-vCPU guest, and fires the alias with memory-mode switches in L1 while L2 activity drives the host's quota reclaim. The chain turns the post-free write into a cross-cache, recovers the KASLR slide, and walks the kernel's log-wait, SRCU workqueue, and usermode-helper paths to create a file named /Zapscape, uid 0, mode 0644, on the host filesystem.[1]

That is a real, working chain on one configuration: AMD nested SVM/NPT on Linux 7.1.3 under QEMU TCG.[1][8] What has not been demonstrated is that chain on any production hardware or on any vendor kernel outside that specific setup. CloudLinux's in-house test says the public proof-of-concept "does not run against CloudLinux-built kernels as written" and, in their reproduction, "crashed the attacker's own guest rather than the host," and they "have not reproduced a guest-to-host escape on any CloudLinux kernel."[7] TuxCare reports the same, an L1 guest crash, and notes the PoC "targets AMD and was developed against a specific Linux 7.1.3 configuration under QEMU TCG rather than on production hardware," and that on RHEL 8 it "does nothing at all there, not even a crash."[8]

So the honest framing, and the one I will hold to throughout: this is a credible full-escape proof-of-concept, demonstrated on AMD in a specific configuration, and not fleet-demonstrated. The worst case on an unpatched, reachable host today is a guest crash and host instability, with a documented but configuration-dependent path to host root.[1][7] No source I checked reports in-the-wild exploitation, and the CISA Known Exploited Vulnerabilities catalog has no entry for the CVE as of 2026-08-31.[9][17]

Two scores for one bug

Red Hat and kernel.org have scored the same flaw differently, and the difference is the assessed exploitability, not the underlying defect.

Both scores are consistent with the same commit. Red Hat's high attack complexity reflects the fact that the public PoC is configuration-dependent demo code, while kernel.org's low complexity and changed scope credit the escape that the researcher documents.[3][4] Neither is "wrong." I am presenting both as fact: a vendor reading that stops at DoS, and a kernel.org reading that credits a full escape, and the vendor testing sits somewhere between the two.[7][8][4]

The Januscape connection

This is the hook I want you to sit with. One month ago, on 2026-07-06, the same researcher disclosed Januscape, CVE-2026-53359, another use-after-free in the KVM x86 shadow MMU. I wrote it up here: Januscape (CVE-2026-53359): KVM Host Escape Vulnerability for Proxmox Operators, published 2026-07-31.[18]

The two flaws are different bugs that happen to live in the same code, in arch/x86/kvm/mmu/. Januscape is a role-word reuse in kvm_mmu_get_child_sp(), where a shadow page is reused on a frame-number match without comparing the role.[18] Zapscape is the stale-root ordering inversion I described above, in the page-fault paths relative to make_mmu_pages_available().[1][2] They are one month apart, by the same person, in the same subsystem, and they need two different fixes with two different commits.[18][2]

The operational point: patching for one does not patch for the other. If you rebooted a node to a Januscape-fixed kernel in late July and never rebooted again, you may still be running a kernel without the Zapscape fix, because the Zapscape backport lands as a later kernel bump on each vendor branch. The same is true in reverse. The shadow MMU has now produced two escape-class flaws in a month, and a single "I patched KVM" check from July does not tell you which bump you actually booted.[18][1]

I should be precise about the Januscape facts I am relying on, because I am cross-linking a published post rather than re-verifying that CVE here. Januscape was disclosed 2026-07-06, is dual-architecture (Intel and AMD), was fixed upstream in two coupled patches, and I covered the Proxmox patching in the linked post.[18] I have not re-verified the Januscape fix commits or its exact per-branch Proxmox kernel versions in this pass, so I am leaving those to the linked post and anchoring the Zapscape-specific version data to the sources cited in this article.

Vendor fix status

The version data below is as of 2026-08-31. Vendor rollouts are still moving, so treat a "fixed" row as the confirmed floor, not the latest build.

Proxmox (pve-kernel)

This is the part that matters most to this blog, and it has a real gap. Proxmox does not run Debian's kernel or any mainline stable release. pve-kernel is derived from Ubuntu's kernel tree, so a Debian advisory or an upstream stable version number proves nothing about the kernel your node actually booted. The only authoritative "am I patched?" source is the pve-kernel git changelog.[12][14]

Two cautions on that table. First, the 6.17 branch (PVE 9.1) is an open gap. I could not find a fixed pve-kernel version for it in the Proxmox forum, the changelog, or any vendor coverage I pulled, and none of the coverage addresses the 6.17 or 6.14 branches at all. If you are on PVE 9.1, do not assume you are covered. Check the pve-kernel git changelog for the 6.17 branch against the upstream fix before you decide you are safe.[11][12]

Second, the next kernel bump after the fix matters. On the 7.0 branch, 7.0.14-10 fixes a different flaw (SCTPhantom, CVE-2026-64564), and 7.0.14-11 is the latest published. A node rebooted at exactly 7.0.14-9 has Zapscape fixed but not SCTPhantom. Same pattern on 6.8, where the next bump after -40 carries the SCTPhantom fix.[12] So "patched for Zapscape" and "current" are not the same thing on Proxmox.

There is also no official Proxmox security advisory for Zapscape that I could find. The Proxmox-side information above comes from the pve-kernel package history and a staff answer in the forum thread, not a PSA.[11][12]

Red Hat

Red Hat's machine-readable security data lists the fix errata and fixed builds. The base RHEL errata are RHSA-2026:45115 (RHEL 8, kernel-4.18.0-553.147.1.el8_10), RHSA-2026:45116 (RHEL 8 realtime), RHSA-2026:45192 (RHEL 9, kernel-5.14.0-687.30.1.el9_8), and RHSA-2026:45114 (RHEL 10, kernel-6.12.0-211.39.1.el10_2), all with a release date of 2026-07-24.[5]

Two things to flag. First, RHEL 9 realtime is still marked "Affected" in the same data, with no fixed RT build listed as of the fetch, so RHEL 9 RT hosts remain exposed even where the base kernel is patched.[5] Second, there is a version conflict in the secondary coverage. TuxCare names 553.147.1 and 687.30.1 as the fixed RHEL builds, which matches the Red Hat machine data and supports 45115/45192 as the fix errata.[8][5] Newer errata, RHSA-2026:49214 (RHEL 8, kernel-4.18.0-553.150.1.el8_10) and RHSA-2026:53329 (RHEL 9, kernel-5.14.0-687.38.1.el9_8), exist and carry newer build numbers, but I could not independently verify that those two advisories actually list this CVE.[19][20] The errata pages are rendered with JavaScript and expose no CVE list in the static HTML, so I am not calling 49214/53329 "the Zapscape errata." If you are on RHEL, check the current advisory against the CVE directly rather than trusting the build number alone.[5]

CloudLinux, Debian, Ubuntu, and others

CloudLinux has patched kernels in beta rolling to stable across 7h, 8, 8 LTS, 9, 9 LTS, and 10, with 7h kernel 3.10 listed as not affected because it predates the Linux 5.9 rule. As of 2026-08-20 the KernelCare livepatches for 7h, 8, 9, and 10 are in the main feed, and the 8/9 LTS and Ubuntu 22.04 livepatches are still in preparation.[7][8]

Debian has fixed versions per the security tracker: trixie at 6.12.101-1 (DSA-6415-1), bookworm at 6.12.101-1~deb12u1 (DLA-4745-1), and unstable at 7.1.6-1.[16]

Ubuntu is the slow one. The official tracker still showed the linux package as Vulnerable for both 24.04 LTS (noble) and 22.04 LTS (jammy) at fetch time on 2026-08-27, with no kernel SRU version published. TuxCare's test-feed KernelCare patches cover Ubuntu 24.04, 24.04 AWS, and 22.04 AWS 6.8 in the interim.[15][8]

CIQ has patched builds for Rocky Linux: kernel-4.18.0-372.32.1.el8_6.86ciq_lts.17.1 for RLC Pro LTS 8.6 and kernel-5.14.0-284.30.1.el9_2.92ciq_lts.14.2 for RLC Pro LTS 9.2, with guidance to disable nesting as the interim mitigation otherwise update.[10]

Operator impact for Proxmox homelab

Here is how I read the risk for a homelab that runs Proxmox. Your exposure is the product of three things, and if any of them is false you are not reachable through this bug.

The first is the host kernel. It must be in the vulnerable window, Linux 5.9 or newer without the 2abd5287f083 fix. On Proxmox that is decided by your pve-kernel version, not by any upstream number, so the check is against the pve-kernel changelog, not the Debian tracker.[12][14]

The second is nested virtualization. The bug is only reachable when a guest can actually run a nested guest, which on a Proxmox node means the KVM host module has nesting allowed and at least one VM is configured to expose virtualization extensions to its guest, either a "host" CPU model or an explicit nested flag. The module parameter nested is read at load time, so disabling it requires a reboot to take effect, not just a module reload.[8][18]

The third is a trusted-attacker boundary. You need a guest you do not fully trust, or a /dev/kvm that an untrusted local user can open. On RHEL-family distros CloudLinux describes /dev/kvm as world-accessible by default, which means a shell account or a compromised web process can open it, build a small guest of its own, and attack the host kernel from inside that guest, no nested-virt configuration on your side required.[7]

The checklist, in the order I would run it on a multi-node cluster:

1. Confirm the booted kernel on every node with uname -r and map it against the fixed-version table above. Do this on the running kernel, not the installed one, because the fix does not take effect until you reboot into the new build.[12]
2. Close the 6.17 / PVE 9.1 gap explicitly. If any node is on PVE 9.1, treat it as unconfirmed and check the 6.17 pve-kernel changelog yourself before you mark it safe.[11][12]
3. Audit which VMs actually expose nested virtualization. List every VM with a host CPU model or an explicit nested flag, and disable the flag on any of them that does not need it. Most homelab VMs do not need nesting, so this is usually a short list and a clean win.[18]
4. Tighten /dev/kvm to 0660 and a kvm group if your node is a shared VPS or runs untrusted local accounts, so the throwaway-guest path is gone even before the kernel is patched.[7]
5. Decide whether your repo is subscription or non-subscription. The patched pve-kernel builds have moved from pve-test to pve-no-subscription and into the enterprise repos, so a node that only pulls from pve-no-subscription or that is not set to follow the no-subscription repo at all will not have received the bump automatically. If your nodes are on the non-subscription repo, the timing of when they picked up the new build is on you to confirm, not on Proxmox pushing it.[12]

The mitigation that is available without a reboot is to turn off nesting where you do not use it. On a node where no workload needs a nested guest, that removes the attack surface entirely and is the right call while you schedule the reboot. On a node where nesting is genuinely in use and you cannot drain it, the only effective mitigation is the patched kernel.[10]

I checked my own node before writing this and its /dev/kvm is already at 0660 root:kvm, which closes that secondary path. A stock RHEL-family VPS is not in that position by default, which is exactly why step 4 is on the checklist.[7]

Operator lab-note: detection commands

These run on a Proxmox node and take seconds. I ran the KVM-level checks (1, 2, 3, and 5) on an AMD KVM host to confirm the paths and the outputs are real, not hypothetical; the Proxmox config grep (4) is the documented /etc/pve/qemu-server pattern, since the booted-kernel and module checks are what the guest path actually depends on.

# 1. Is the KVM host module even loaded?
lsmod | grep kvm
# No output = this node is not a KVM host, you are outside this attack surface.
# My node returns kvm and kvm_amd. On an Intel node you would see kvm_intel instead.

# 2. Does the loaded module allow nested virtualization?
# AMD host:
cat /sys/module/kvm_amd/parameters/nested
# Intel host (this file does not exist on an AMD node):
cat /sys/module/kvm_intel/parameters/nested
# "1" or "Y" = nested is allowed at the host level. "0" or "N" = nested is off
# at the host gate, which removes the attack surface even if a VM asks for it.

# 3. What kernel is actually running (not just installed)?
uname -r
# Compare against the fixed pve-kernel version for your PVE branch above.
# The fix only counts if this booted version is at or past it.

# 4. Which VMs expose nested virt to a guest?
# A VM only reaches the bug if it is configured to expose virtualization
# extensions, i.e. a "host" CPU model or an explicit nested flag.
# (In a current Proxmox config the flag lives on the cpu: line, e.g.
# "cpu: host" or "cpu: host,nested=1"; -nested / -cpu host in args: is
# the legacy/CLI spelling. Grep both so you do not miss either.)
grep -HlE 'cpu:.*host|args:.*(-nested|-cpu host)' /etc/pve/qemu-server/*.conf
# Each line printed is a VM whose config exposes nested virt to a guest.
# No output = no VM is exposing nested virt to a guest, you are not reachable
# through the guest path even if the kernel is in the vulnerable window.

# 5. Can an untrusted local user open /dev/kvm?
ls -l /dev/kvm
# 0660 root:kvm = only the kvm group can open it (my node, hardened).
# 0666 = world-accessible, the throwaway-guest path is open on RHEL-family nodes.

One subtlety on step 2. There are two gates, and both must be open for the guest path. The module nested parameter is the host-level gate and is read when the module loads, so flipping it needs a reboot. The per-VM flag or host CPU model is the second gate, and it is what a specific guest actually sees. A node with nested=1 but no VM exposing it is not reachable, and a node with nested=0 is not reachable even if a VM config asks for nesting. The lsmod plus nested parameter tells you the host gate; the config grep tells you the per-VM gate.[8][18]

For the host-gate check, note that the file you read depends on the CPU vendor. An AMD node has /sys/module/kvm_amd/parameters/nested and no intel file; an Intel node is the reverse. Run the one that exists on your node.

What not to do

Do not read the Intel precondition onto an AMD host or vice versa. The Intel path needs both EPT walk lengths 4 and 5 exposed to L1, which limits it to Ice Lake-SP and newer with those capabilities passed through. The AMD path has no documented CPU-feature gate at all. Conflating the two is how an operator concludes their Intel box is the only exposed one and skips the AMD node, which is the more directly reachable of the two.[1][8]

Do not treat the 7.0.14-9 / 6.8.12-40 versions as "current." They are the Zapscape floor. The next bumps carry SCTPhantom, so a node on exactly the fix version is one flaw behind current.[12]

Do not count the CISA KEV catalog as your risk signal. The CVE is not listed, which is consistent with no confirmed exploitation, but the absence of a listing is not the absence of risk, and the public chain is real on a reachable configuration. Patch on the kernel version, not on a watchlist.[17][1]

Do not assume your January-or-July KVM reboot covered this. If you booted a Januscape-fixed kernel and stopped there, you may be one bump short of the Zapscape fix. Check the running kernel number, not your memory of having patched KVM this summer.[18][1]

Related

The Januscape deep-dive is the companion piece for this one: Januscape (CVE-2026-53359): KVM Host Escape Vulnerability for Proxmox Operators, published 2026-07-31. It covers the role-word root cause, the 9-step chain, and the Proxmox patching that this article builds on. [18]

Belgium's Centre for Cybersecurity issued a public advisory on 2026-07-08 warning about both Januscape and Zapscape as KVM VM-escape risks, so the "two in a month, same researcher, same code" pattern is not only my framing, it is what the national CSIRTs are tracking.[21]

Dirty Frag is a separate in-flight lab-note on this site. It is a host-local privilege escalation, not a guest escape, so it is a different attack vector than Zapscape and is noted here only to keep the two from being conflated. It will be linked when it ships.

Sources

1. https://github.com/V4bel/Zapscape/blob/main/assets/write-up.md — V4bel/Zapscape technical write-up (Hyunwoo Kim): root cause, exploit chain, PoC
2. https://github.com/torvalds/linux/commit/2abd5287f08319fa35764566b15c6e22cb1068db — Upstream fix commit 2abd5287f083: KVM: x86: Check for invalid/obsolete root after making MMU pages available
3. https://nvd.nist.gov/vuln/detail/CVE-2026-64561 — NVD: CVE-2026-64561 (kernel.org CNA data, stable fix list, CVSS 8.8)
4. https://access.redhat.com/security/cve/cve-2026-64561 — Red Hat CVE-2026-64561 (CVSS 7.0 Important, CWE-825, impact framing)
5. https://access.redhat.com/hydra/rest/securityData/cve/CVE-2026-64561 — Red Hat security data API: CVE-2026-64561 (advisories, fixed builds, affected states)
6. https://thehackernews.com/2026/08/new-zapscape-kvm-flaw-could-let.html — The Hacker News: New Zapscape KVM Flaw Could Let Privileged L1 Guest Code Escape to Linux Hosts (Aug 6, 2026)
7. https://blog.cloudlinux.com/zapscape-cve-2026-64561-kvm-guest-escape-and-local-root-mitigation-and-kernel-update-for-cloudlinux — CloudLinux advisory: Zapscape KVM guest escape and local root (updated Aug 20, 2026)
8. https://tuxcare.com/blog/zapscape-cve — TuxCare: Zapscape Explained and How to Protect KVM Hosts (status Aug 11, 2026)
9. https://penligent.ai/hackinglabs/pt/cve-2026-64561 — Penligent: CVE-2026-64561 Zapscape analysis (scope, limits, no real-world claims as of Aug 7)
10. https://kb.ciq.com/article/security-advisories/cve-zapscape-mitigation — CIQ KB: Mitigating Zapscape on Rocky Linux (patched kernel table)
11. https://forum.proxmox.com/threads/proxmox-and-cve-2026-64561.185571 — Proxmox forum: Proxmox and CVE-2026-64561 (staff: fixed pve-kernel versions)
12. https://everywan.com/en/blog/zapscape-sctphantom-proxmox-does-not-run-debians-kernel — everyWAN: Zapscape and SCTPhantom (pve-kernel fixed versions 7.0.14-9, 6.8.12-40)
13. https://pve.proxmox.com/wiki/Proxmox_VE_Kernel — Proxmox VE Kernel wiki (PVE-to-kernel lineage)
14. https://ubuntu.com/security/CVE-2026-64561 — Ubuntu security tracker: CVE-2026-64561 (noble/jammy status at fetch time)
15. https://security-tracker.debian.org/tracker/CVE-2026-64561 — Debian security tracker: CVE-2026-64561 (fixed versions per release, DSA-6415-1)
16. https://www.cisa.gov/known-exploited-vulnerabilities-catalog — CISA Known Exploited Vulnerabilities Catalog
17. https://blog.malwlab.se/januscape-cve-2026-53359-kvm-host-escape-vulnerability-for-proxmox-operators — Malwlab: Januscape (CVE-2026-53359) KVM Host Escape for Proxmox Operators (published 2026-07-31)
18. https://access.redhat.com/errata/RHSA-2026:49214 — RHSA-2026:49214: RHEL 8 kernel security update (kernel-4.18.0-553.150.1.el8_10)
19. https://access.redhat.com/errata/RHSA-2026:53329 — RHSA-2026:53329: RHEL 9 kernel security update (kernel-5.14.0-687.38.1.el9_8)
20. https://ccb.belgium.be/advisories/warning-vm-escape-vulnerabilities-kvm-patch-immediately — Belgium Centre for Cybersecurity: warning on KVM VM-escape vulnerabilities (Zapscape + Januscape)
21. https://github.com/V4bel/Zapscape — V4bel/Zapscape: public PoC and write-up repository