CVE-2026-64561 (Zapscape): KVM Nested Virtualization Escape — Detection and Remediation Guide for Linux Hosts | Security Arsenal

A newly disclosed Linux kernel vulnerability dubbed Zapscape (CVE-2026-64561) strikes at one of the most dangerous assumptions in virtualized infrastructure: that the hypervisor boundary holds. The flaw lives in KVM/x86's shadow memory management unit (MMU) — the component responsible for shadow paging — and it allows an attacker who already has kernel-level privileges inside an L1 guest VM to escape KVM isolation and execute code on the underlying Linux host.

Let me be blunt about the risk model here. This is not a remote, unauthenticated exploit. The attacker needs privileged code execution inside a nested (L1) guest first. But if you operate multi-tenant infrastructure, cloud hosting, CI/CD sandboxing, malware detonation environments, or any architecture where untrusted workloads run inside nested guests, that precondition may already be satisfied — or one guest-to-guest compromise away from being satisfied. A VM escape converts a single-tenant compromise into full host control, which means every other guest on that hypervisor is now in scope.

The immediate defensive priority is simple: determine whether nested virtualization is enabled on your KVM hosts, and if so, whether any untrusted L1 guests can reach it. Everything else follows from that answer.

Technical Analysis

Affected Component and Platforms

Component: KVM/x86 shadow MMU (shadow paging path), Linux kernel
Affected architecture: x86 virtualization hosts using KVM with nested virtualization exposed to L1 guests
Attack prerequisite: Attacker must already possess kernel privileges within an L1 guest virtual machine
Exposure condition: Nested virtualization must be enabled on the host (the nested parameter on kvm_intel or kvm_amd) and the L1 guest must itself be permitted to act as a hypervisor (L0 → L1 → L2 topology)

The shadow MMU exists to handle cases where hardware-assisted paging (EPT on Intel, NPT on AMD) is unavailable, disabled, or inapplicable — which is precisely the situation that arises in nested virtualization scenarios where the L1 guest runs its own L2 guests. KVM maintains shadow page tables that translate guest virtual addresses to host physical addresses across multiple levels of indirection. That translation layer is complex, historically bug-prone, and — per this disclosure — contains a flaw exploitable by a malicious L1 guest kernel to corrupt or manipulate shadow page state in a way that escapes to the host (L0).

How the Attack Works (Defender's View)

The exploitation chain, from a blue-team perspective:

Pre-positioning: The attacker gains kernel/root privileges inside an L1 guest. This could come from a separate guest-OS compromise, a malicious tenant in a hosting environment, or a deliberately weaponized workload.
Triggering the shadow MMU path: The attacker exercises KVM's shadow paging code from within the L1 guest — for example, by manipulating nested page table state in ways that force the host's shadow MMU to process attacker-influenced translations.
Isolation breach: The flaw in shadow MMU handling allows the L1 guest to break out of its KVM confinement and achieve code execution in host (ring 0 / hypervisor) context.
Post-escape: Host-level code execution means full control over the hypervisor and every guest it hosts — data theft, lateral movement, implant persistence below the guest layer, or destruction of the entire virtualization stack.

Exploitation Status

At the time of this writing, the disclosure describes a viable escape path rather than a confirmed mass-exploitation campaign. There is no public confirmation of in-the-wild abuse or CISA KEV inclusion in the source material. That said, VM escape vulnerabilities are among the most aggressively pursued bug classes by advanced actors and exploit brokers — the window between disclosure and weaponization for hypervisor escapes has historically been short. Treat this as patch-or-mitigate now, not "monitor and wait."

Detection & Response

Detection for a hypervisor escape is inherently hard: once an attacker is executing on the host, guest-level telemetry is untrustworthy, and the escape itself may leave minimal artifacts. Your realistic detection surface is (a) identifying the exposure condition before exploitation — nested virtualization enabled with untrusted L1 guests — and (b) catching pre-escape staging and host-side anomalies in kernel logs. Focus your hunts there.

YAML

---
title: KVM Nested Virtualization Module Parameter Enabled or Toggled
description: Detects loading or reconfiguration of KVM kernel modules with nested virtualization enabled, which expands the attack surface for CVE-2026-64561 (Zapscape) shadow MMU escape.
references:
  - https://thehackernews.com/2026/08/new-zapscape-kvm-flaw-could-let.html
  - https://attack.mitre.org/techniques/T1611/
author: Security Arsenal
date: 2026/08/10
id: 3f9a2c71-8b4d-4e5a-9c1f-2d7e6a5b8c09
status: experimental
tags:
  - attack.privilege_escalation
  - attack.t1611
logsource:
  category: process_creation
  product: linux
detection:
  selection_modprobe:
    Image|endswith:
      - '/modprobe'
      - '/insmod'
    CommandLine|contains:
      - 'kvm_intel'
      - 'kvm_amd'
  selection_nested_param:
    CommandLine|contains:
      - 'nested=1'
      - 'nested=Y'
      - 'nested=y'
  selection_sysctl_write:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/tee'
    CommandLine|contains:
      - '/sys/module/kvm_intel/parameters/nested'
      - '/sys/module/kvm_amd/parameters/nested'
      - '/etc/modprobe.d/'
  condition: (selection_modprobe and selection_nested_param) or selection_sysctl_write
falsepositives:
  - Legitimate hypervisor provisioning or kernel module management by virtualization administrators
  - Infrastructure-as-code tooling configuring KVM hosts
level: high
---
title: QEMU/KVM Guest Launched With Nested Virtualization CPU Exposure
description: Detects QEMU virtual machine launches that expose virtualization extensions (VMX/SVM) to guests, a precondition for the L1 guest attack surface abused by CVE-2026-64561 (Zapscape).
references:
  - https://thehackernews.com/2026/08/new-zapscape-kvm-flaw-could-let.html
  - https://attack.mitre.org/techniques/T1611/
author: Security Arsenal
date: 2026/08/10
id: 7b1e4d92-3c6f-4a8b-b5d2-9e1f7a3c6d84
status: experimental
tags:
  - attack.privilege_escalation
  - attack.t1611
logsource:
  category: process_creation
  product: linux
detection:
  selection_qemu:
    Image|contains:
      - 'qemu-system'
      - 'qemu-kvm'
  selection_cpu_flags:
    CommandLine|contains:
      - '-cpu host'
      - '+vmx'
      - '+svm'
      - 'vmx=on'
  condition: selection_qemu and selection_cpu_flags
falsepositives:
  - Legitimate nested virtualization labs, CI runners, and virtualization development environments
  - Managed cloud/hypervisor platforms intentionally providing nested virt to tenants
level: medium
---
title: KVM Shadow MMU Kernel Error or VM-Exit Anomaly in Host Logs
description: Detects kernel log signatures consistent with KVM shadow paging faults, MMU errors, or abnormal VM-exit conditions on the host that may indicate attempted exploitation of the Zapscape shadow MMU flaw (CVE-2026-64561).
references:
  - https://thehackernews.com/2026/08/new-zapscape-kvm-flaw-could-let.html
  - https://attack.mitre.org/techniques/T1611/
author: Security Arsenal
date: 2026/08/10
id: 2c5f8a14-6d9b-4e7a-a3f1-8b2d5e9c4a67
status: experimental
tags:
  - attack.privilege_escalation
  - attack.t1611
logsource:
  service: kernel
  product: linux
detection:
  selection_kvm_mmu:
    - 'kvm: ':
        - 'shadow page'
        - 'mmu'
    - 'BUG':
        - 'kvm'
        - 'mmu_notifier'
    - 'general protection fault':
        - 'kvm'
    - 'kernel NULL pointer dereference':
        - 'kvm'
  condition: selection_kvm_mmu
falsepositives:
  - Hardware instability or memory errors producing kernel faults
  - Other unrelated KVM bugs on heavily loaded hypervisors
level: high

KQL — Microsoft Sentinel / Defender

// Hunt: KVM nested virtualization exposure and shadow MMU anomalies on Linux hypervisors
// Scope: Syslog (CEF/agent-ingested Linux host logs) in Microsoft Sentinel
// Look for: kvm module loads with nested=1, qemu launches exposing VMX/SVM, kernel MMU faults

let lookback = 7d;
Syslog
| where TimeGenerated > ago(lookback)
| where SyslogMessage has_any (
    "kvm_intel", "kvm_amd",
    "nested=1",
    "/sys/module/kvm_intel/parameters/nested",
    "/sys/module/kvm_amd/parameters/nested",
    "qemu-system", "qemu-kvm",
    "+vmx", "+svm", "-cpu host",
    "shadow page", "mmu_notifier",
    "BUG: unable to handle kernel", "general protection fault"
  )
| extend Indicator = case(
    SyslogMessage has "nested=1", "Nested virtualization enabled",
    SyslogMessage has_any ("+vmx", "+svm", "-cpu host"), "Guest launched with virt extensions",
    SyslogMessage has_any ("shadow page", "mmu_notifier", "BUG", "general protection fault"), "KVM MMU/fault anomaly",
    "KVM module activity")
| summarize EventCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), SampleMessages = make_set(SyslogMessage, 5)
    by Computer, Indicator, ProcessName
| order by LastSeen desc;

VQL — Velociraptor

-- Hunt: Identify KVM hosts with nested virtualization enabled and guests exposing virt extensions
-- Relevant to CVE-2026-64561 (Zapscape) exposure assessment across a Linux hypervisor fleet

LET nested_params <= SELECT FullPath, Data
FROM read_file(filenames=[
    '/sys/module/kvm_intel/parameters/nested',
    '/sys/module/kvm_amd/parameters/nested'
])

SELECT FullPath AS NestedParamPath,
       Data AS NestedParamValue
FROM nested_params

UNION ALL

SELECT Exe AS NestedParamPath,
       CommandLine AS NestedParamValue
FROM pslist()
WHERE CommandLine =~ 'qemu-system|qemu-kvm'
  AND CommandLine =~ '\\+vmx|\\+svm|-cpu host'

Bash / Shell

#!/bin/bash
# CVE-2026-64561 (Zapscape) — KVM nested virtualization exposure check and mitigation
# Run as root on Linux KVM hypervisors. Audit first, then mitigate if nested virt is not required.

echo "=== [1] Check current nested virtualization state ==="
for param in /sys/module/kvm_intel/parameters/nested /sys/module/kvm_amd/parameters/nested; do
  if [ -f "$param" ]; then
    echo "$(hostname): $param = $(cat $param)"
  fi
done

echo ""
echo "=== [2] Check persistent module configuration ==="
grep -r "options kvm" /etc/modprobe.d/ /etc/modprobe.conf 2>/dev/null || echo "No KVM modprobe options found."

echo ""
echo "=== [3] Check running kernel against patched state ==="
echo "Current kernel: $(uname -r)"
echo "Verify this kernel includes the CVE-2026-64561 shadow MMU fix per your distribution's security advisory."

echo ""
echo "=== [4] MITIGATION (if nested virt is NOT required): disable nested virtualization ==="
read -p "Disable nested virtualization now? (yes/no): " confirm
if [ "$confirm" = "yes" ]; then
  if [ -f /sys/module/kvm_intel/parameters/nested ]; then
    echo 'options kvm_intel nested=0' > /etc/modprobe.d/kvm-nested-disable.conf
  elif [ -f /sys/module/kvm_amd/parameters/nested ]; then
    echo 'options kvm_amd nested=0' > /etc/modprobe.d/kvm-nested-disable.conf
  fi
  echo "Persisted nested=0 in /etc/modprobe.d/kvm-nested-disable.conf"
  echo "Reloading KVM modules (WARNING: this tears down running VMs — schedule a maintenance window)..."
  read -p "Proceed with module reload? (yes/no): " reload
  if [ "$reload" = "yes" ]; then
    modprobe -r kvm_intel kvm_amd kvm 2>/dev/null
    modprobe kvm
    modprobe kvm_intel 2>/dev/null || modprobe kvm_amd 2>/dev/null
    echo "Modules reloaded. Verify:"
    cat /sys/module/kvm_intel/parameters/nested 2>/dev/null || cat /sys/module/kvm_amd/parameters/nested 2>/dev/null
  else
    echo "Skipped reload. nested=0 will take effect at next reboot."
  fi
else
  echo "No changes made. If nested virt IS required, ensure only trusted L1 guests can use it and patch the kernel urgently."
fi

echo ""
echo "=== [5] Audit recent kernel logs for KVM MMU anomalies ==="
journalctl -k --since "7 days ago" 2>/dev/null | grep -iE "kvm.*(mmu|shadow page)|BUG.*kvm|general protection fault" | tail -20 || echo "No anomalies found in recent kernel logs."

Remediation

Patch the kernel. Apply the latest stable kernel updates from your Linux distribution that address CVE-2026-64561 (shadow MMU fix in KVM/x86). Track your vendor's security advisory — check the National Vulnerability Database entry for CVE-2026-64561 and your distribution's security tracker (Red Hat, Ubuntu, Debian, SUSE) for the fixed package versions and vendor advisory URLs. Because this is a host-kernel fix, remediation requires a reboot or live-patching (kpatch/kGraft) if your platform supports it.
Disable nested virtualization where it isn't a hard business requirement. This is the highest-leverage workaround and fully removes the attack surface: set options kvm_intel nested=0 (or kvm_amd nested=0) in /etc/modprobe.d/, reload the KVM modules during a maintenance window, and verify with cat /sys/module/kvm_intel/parameters/nested. Most production hypervisors do not legitimately need nested virt — it's commonly enabled by default or left on from lab configurations.
If nested virtualization is required, harden the trust boundary. Ensure only fully trusted, controlled L1 guests receive virtualization extensions (VMX/SVM). Never expose nested virt to tenant-controlled, third-party, or ephemeral workloads (CI runners, sandbox detonation environments) until the host kernel is patched. Audit QEMU/libvirt configurations for guests launched with -cpu host, +vmx, or +svm.
Enforce strong isolation inside L1 guests. Since exploitation requires kernel privileges in the L1 guest, raise the cost of that prerequisite: minimize guest attack surface, enforce SELinux/AppArmor, restrict kernel module loading, and keep guest kernels patched. Treat every L1 guest with nested virt access as a potential host-compromise vector.
Monitor hypervisor hosts directly, not through guests. Ship host kernel logs (journald/syslog) to your SIEM out-of-band, deploy the detections above, and alert on KVM MMU faults, unexpected module reloads, and nested-parameter changes. After an escape, guest telemetry is untrustworthy — host-level visibility is your ground truth.
Inventory and prioritize. Build a fleet-wide list of KVM hosts with nested=1 exposed to any non-fully-trusted L1 guest. Those are your P0 remediation targets. Hosts with nested virt disabled are not exposed to this escape path and can follow the normal kernel patch cadence.

The defensive lesson here extends beyond this CVE: nested virtualization is a privileged capability, not a convenience feature. If your architecture hands it to untrusted guests, you've widened the hypervisor trust boundary to include every bug in the shadow paging path — past and future. Audit it, restrict it, and patch it.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub

CVE-2026-64561 (Zapscape): KVM Nested Virtualization Escape — Detection and Remediation Guide for Linux Hosts