In the Linux kernel

CVE-2026-64561, dubbed Zapscape, is a use-after-free vulnerability in the KVM x86 shadow MMU emulation. The flaw lives in the recursive zap path that fires when KVM reclaims shadow pages during memory pressure. When nested virtualization is enabled, KVM falls back from hardware-assisted paging (EPT/NPT) to its legacy software shadow MMU — and the recursive zap path fails to check root_count guards properly. A guest VM (L1) can trigger a nested guest (L2) memory access pattern that forces the host (L0) into quota reclaim, corrupting shadow page table entries and achieving a use-after-free in host kernel memory. Affected kernels span from commit f95eec9bed76 (July 2020) through commit 2abd5287f083 (July 21, 2026) — roughly six years of mainline Linux kernels. The PoC demonstrates full code execution on the host, creating a /Zapscape file owned by root on L0 from within L1.

No vendor CVSS has been assigned. Given the impact class — guest-to-host VM escape achieving host kernel code execution — this is objectively a critical-severity vulnerability. The only meaningful friction is the requirement for nested virtualization to be enabled, which forces KVM through the vulnerable shadow paging path. On modern hardware with EPT (Intel) or NPT (AMD) and nested virt *disabled*, the shadow MMU code is largely dormant and the bug is unreachable. However, nested virtualization is explicitly enabled on a meaningful share of KVM deployments: Google Cloud, Azure nested-virt instance types, and many private clouds running CI/CD or development workloads with nested VMs. The absence of a vendor score should not lull teams into treating this as a routine kernel fix.

Why this verdict

• Hypervisor escape with public weaponized PoC: The Zapscape PoC on GitHub achieves full host kernel code execution from within a guest VM, not just a DoS/panic. The weaponization barrier is effectively zero for any attacker with guest root access on a nested-virt-enabled host.
• Role multiplier — KVM is a hypervisor by definition: Every KVM installation is a hypervisor. A successful exploit gives the attacker control of L0, meaning they own every guest VM on that physical host. In cloud and multi-tenant environments, this is fleet-scale compromise from a single rented instance. The blast radius is host → all co-tenant VMs → potential lateral movement to other hosts.
• Nested virtualization is the sole meaningful friction point, but it does not break the CRITICAL floor: Nested virt must be enabled for the shadow MMU path to be exercised. This is not the default on most distros, but it is explicitly enabled on Google Cloud nested-virt instances, Azure nested-virt SKUs, and private clouds running CI/CD, Kubernetes-in-KVM, or development workloads. Estimated 5-20% of KVM hosts — well above the 1% threshold for a HIGH floor and arguably above 10% for CRITICAL.
• No authentication barrier beyond guest root: In the threat model KVM exists to enforce (untrusted tenants), guest root is the *starting* position. Requiring guest root is not friction — it is the baseline attacker capability KVM must defend against.
• Six-year vulnerability window: The bug was introduced in July 2020 and fixed in July 2026. Any kernel from ~5.8 through 7.1.x is affected. The long tail of unpatched kernels in enterprise environments means exposure will persist for months.

Why not higher?

A 9.0 rather than 10.0 because the attack requires nested virtualization to be explicitly enabled, which is not the default configuration. On hosts without nested virt, the shadow MMU path is dormant and the vulnerability is unreachable. Additionally, the current PoC targets AMD specifically, though the underlying bug likely affects Intel shadow paging paths as well.

Why not lower?

Downgrading below CRITICAL would require evidence that fewer than 10% of KVM installations have nested virtualization enabled AND that the blast radius is somehow contained. Neither condition holds: nested virt is common in cloud and CI/CD environments, and the blast radius is total host compromise affecting all co-tenant workloads. The public PoC eliminates any argument about theoretical-only exploitation. A hypervisor escape with a working public exploit cannot be MEDIUM or LOW under any reasonable risk framework.

1. Disable nested virtualization on all KVM hosts where it is not operationally required — Set nested=0 for kvm_amd and kvm_intel modules. This prevents KVM from exercising the vulnerable shadow MMU path entirely, eliminating the attack surface. Deploy within 3 days per noisgate mitigation SLA for CRITICAL. Run: echo 'options kvm_amd nested=0' > /etc/modprobe.d/kvm-no-nested.conf and reload the module or reboot. For Intel: options kvm_intel nested=0.
2. Audit and inventory all KVM hosts with nested virtualization enabled — Query your fleet for hosts where /sys/module/kvm_amd/parameters/nested or kvm_intel equivalent returns Y or 1. These hosts are your immediate patch priority. Use your CMDB or run the verification script below across your hypervisor fleet.
3. Restrict /dev/kvm permissions — Ensure /dev/kvm is not world-writable. On hosts where unprivileged users can access /dev/kvm, the vulnerability escalates from a guest-escape to a local privilege escalation. Verify permissions: ls -la /dev/kvm should show crw-rw---- root kvm.
4. Apply kernel update containing fix commit 2abd5287f083 — This is the definitive remediation. Update to the first stable kernel in your distro that contains this commit. Also apply fixes for the related CVEs (CVE-2026-53359, CVE-2026-46113) to fully harden the shadow MMU. Target within 90 days per noisgate remediation SLA for CRITICAL.
5. Enable KASAN on staging/canary hypervisors — Kernel Address Sanitizer can detect use-after-free conditions at runtime. While too expensive for production, enabling it on canary nodes can validate that your patched kernel no longer exhibits the bug.

Run this script on each KVM hypervisor host as root. It checks whether the running kernel contains the vulnerable code range and whether nested virtualization is enabled. Invoke with: sudo bash check_zapscape.sh

#!/usr/bin/env bash
# check_zapscape.sh — CVE-2026-64561 (Zapscape) exposure checker
# Run as root on KVM hypervisor hosts.
# Exit codes: 0 = PATCHED/not affected, 1 = VULNERABLE, 2 = UNKNOWN

set -euo pipefail

RED='\033[0;31m'; GREEN='\033[0;32m'; YELLOW='\033[1;33m'; NC='\033[0m'

# Check if KVM is loaded
if ! lsmod | grep -q '^kvm '; then
  echo -e "${GREEN}PATCHED${NC} — KVM module is not loaded. This host is not a KVM hypervisor."
  exit 0
fi

# Check kernel version
KERNEL=$(uname -r)
echo "[*] Running kernel: $KERNEL"

# Check for the fix commit in the kernel changelog/version
# The fix commit is 2abd5287f083, landed 2026-07-21
# Affected range: ~5.8 (2020-07) through pre-fix kernels
MAJOR=$(echo "$KERNEL" | cut -d. -f1)
MINOR=$(echo "$KERNEL" | cut -d. -f2)
PATCH=$(echo "$KERNEL" | cut -d. -f3 | cut -d- -f1)

VULNERABLE_KERNEL=false

if [ "$MAJOR" -gt 7 ]; then
  VULNERABLE_KERNEL=false
elif [ "$MAJOR" -eq 7 ] && [ "$MINOR" -ge 2 ]; then
  VULNERABLE_KERNEL=false
elif [ "$MAJOR" -eq 7 ] && [ "$MINOR" -eq 1 ] && [ "$PATCH" -ge 4 ]; then
  VULNERABLE_KERNEL=false
elif [ "$MAJOR" -ge 5 ] && [ "$MINOR" -ge 8 ] || [ "$MAJOR" -ge 6 ]; then
  VULNERABLE_KERNEL=true
elif [ "$MAJOR" -eq 5 ] && [ "$MINOR" -ge 8 ]; then
  VULNERABLE_KERNEL=true
else
  VULNERABLE_KERNEL=false
fi

# Override: check for distro-specific backports via changelog
if command -v rpm &>/dev/null; then
  if rpm -q --changelog kernel-"$KERNEL" 2>/dev/null | grep -qi 'CVE-2026-64561\|2abd5287f083'; then
    echo -e "${GREEN}PATCHED${NC} — Kernel $KERNEL contains the fix for CVE-2026-64561 (detected via RPM changelog)."
    exit 0
  fi
elif command -v dpkg &>/dev/null; then
  if apt changelog "linux-image-$KERNEL" 2>/dev/null | grep -qi 'CVE-2026-64561\|2abd5287f083'; then
    echo -e "${GREEN}PATCHED${NC} — Kernel $KERNEL contains the fix for CVE-2026-64561 (detected via dpkg changelog)."
    exit 0
  fi
fi

if [ "$VULNERABLE_KERNEL" = false ]; then
  echo -e "${GREEN}PATCHED${NC} — Kernel $KERNEL is outside the affected version range."
  exit 0
fi

# Check nested virtualization status
NESTED_ENABLED=false
for MOD in kvm_amd kvm_intel; do
  NESTED_FILE="/sys/module/$MOD/parameters/nested"
  if [ -f "$NESTED_FILE" ]; then
    VAL=$(cat "$NESTED_FILE")
    if [ "$VAL" = "1" ] || [ "$VAL" = "Y" ]; then
      NESTED_ENABLED=true
      echo "[!] Nested virtualization is ENABLED ($MOD)"
    else
      echo "[*] Nested virtualization is disabled ($MOD)"
    fi
  fi
done

if [ "$VULNERABLE_KERNEL" = true ] && [ "$NESTED_ENABLED" = true ]; then
  echo -e "${RED}VULNERABLE${NC} — Kernel $KERNEL is in the affected range AND nested virtualization is enabled. CVE-2026-64561 (Zapscape) is exploitable."
  exit 1
elif [ "$VULNERABLE_KERNEL" = true ] && [ "$NESTED_ENABLED" = false ]; then
  echo -e "${YELLOW}VULNERABLE${NC} (mitigated) — Kernel $KERNEL is in the affected range but nested virtualization is disabled. The attack path is currently blocked, but patching is still required."
  exit 1
else
  echo -e "${YELLOW}UNKNOWN${NC} — Could not definitively determine patch status for kernel $KERNEL. Verify manually."
  exit 2
fi

Sources

1. Zapscape PoC — V4bel/Zapscape on GitHub
2. The Hacker News — 16-Year-Old Linux KVM Flaw Lets Guest VMs Escape
3. TuxCare — Januscape Exposes the KVM Shadow Paging Bug That Kept Coming Back
4. Corgea — CVE-2026-53359 Januscape KVM VM Escape Analysis
5. WindowsForum — CVE-2026-46113 KVM Shadow Paging Use-After-Free
6. TechTimes — Linux KVM Guest-to-Host Escape Hits Both Intel and AMD
7. CISA Vulnerability Summary — Week of July 6, 2026