ELSEIF
Your brief EB
302 stories from 73 feeds 95 clusters Refreshed 8 minutes ago next pull 19:06

TECH Signal 599 2 feeds carried it

Zapscape (CVE-2026-64561)

Zapscape (CVE-2026-64561) is a use-after-free bug in KVM’s shadow MMU that lets a guest VM execute code with root privileges on the host.

WHY IT MATTERS

The flaw breaks the isolation guarantees of KVM, allowing an attacker who controls a single VM to take over the host or disrupt other tenants in a public-cloud setting. Because the exploit works with guest-side actions alone, any untrusted guest that gains root inside its VM can trigger the escape, and on systems where /dev/kvm is world-writable it also serves as a local privilege escalation vector.

Written by elseif from the cluster below · every claim links back to a source

The three things worth knowing

01

The vulnerability resides in the recursive zap path of the shadow page reclamation logic and can be triggered without any host-side interaction.

02

Exploitation requires root inside the guest and can be demonstrated on AMD hardware, with Intel impact limited to configurations exposing certain EPT page-walk lengths.

03

Mitigation involves applying kernel patches that cover the commit range from f95eec9bed76 to 2abd5287f083 and tightening /dev/kvm permissions or disabling nested virtualization for untrusted workloads.

THE READ

What the cluster adds up to.

ORIGINAL ANALYSIS

Zapscape exploits a use-after-free condition in the shadow MMU emulation of KVM on x86 platforms. The bug appears in the recursive cleanup routine that runs when shadow pages are reclaimed, allowing a guest to corrupt host kernel structures. By corrupting these structures the attacker can gain code execution in the host kernel with root privileges. This breaks the fundamental guest-to-host isolation that KVM provides.

The practical impact is severe: a malicious tenant can either bring down the entire physical host, affecting all co-located VMs, or execute arbitrary commands as root on the host. In environments where the KVM device node is world-writable, the same flaw can be leveraged as a local privilege escalation on the host itself, simplifying the exploit chain. Consequently, any multi-tenant public cloud or private data-center using KVM/x86 must treat this as a critical risk.

The proof-of-concept targets AMD processors and demonstrates the attack using three nested layers: the host (L0), a guest that creates a malicious module (L1), and a further nested VM (L2) that triggers the recursive zap. The exploit requires root inside the L1 guest to manipulate page tables and provoke the use-after-free. While the PoC runs under QEMU’s TCG emulator for safety, moving the payload into a real guest kernel module and adapting it to the host’s kernel configuration would enable a live cloud attack.

Mitigation is straightforward: apply the kernel patches that span the identified commit range, which close the use-after-free in the shadow MMU. Administrators should also review the permissions on /dev/kvm, restricting write access to trusted users, and consider disabling nested virtualization for untrusted workloads. For Intel hosts, ensuring that the extended page-table walk lengths that trigger the bug are not exposed further reduces the attack surface.

Operators should test the patched kernel in an isolated environment before deployment, using the provided PoC only on authorized systems. Verifying that the host kernel version is newer than the last vulnerable commit eliminates the immediate threat. Ongoing vigilance is required because the vulnerability can be adapted to different host configurations once the basic exploit chain is understood.

Written by elseif from the cluster below · checked for specifics the sources never contained

THE CLUSTER

Same story, 2 feeds.

ORDERED BY FIRST SEEN
Lobsters Zapscape - Guest to host escape in KVM/x86 Open ↗
Hacker News Zapscape (CVE-2026-64561) Open ↗