{"id":1899,"date":"2026-08-07T07:25:35","date_gmt":"2026-08-07T00:25:35","guid":{"rendered":"https:\/\/vncybers.vn\/canh-bao-zapscape-lo-hong-kvm-guest-thoat-ra-host-linux\/"},"modified":"2026-08-07T11:33:05","modified_gmt":"2026-08-07T04:33:05","slug":"zapscape-kvm-flaw-guest-escape-linux-host","status":"publish","type":"post","link":"https:\/\/vncybers.vn\/en\/zapscape-kvm-flaw-guest-escape-linux-host\/","title":{"rendered":"Zapscape Alert: New KVM Flaw Could Let Guest Escape to Linux Host"},"content":{"rendered":"

A new vulnerability in Linux KVM, named Zapscape<\/strong> and tracked as CVE-2026-64561<\/strong>, could allow malicious code with kernel privileges inside an L1 guest virtual machine to break out of the virtualization boundary and execute code on the Linux host.<\/p>\n

Information published by The Hacker News on August 6, 2026, shows that the risk is concentrated in environments that expose nested virtualization<\/em> to untrusted guests. This pattern is often seen in labs, infrastructure testing services, self-hosted CI\/CD platforms, or virtualization clusters that allow customers to run a nested hypervisor inside a virtual machine.<\/p>\n

\"Linux<\/p>\n

Where the KVM flaw sits<\/h2>\n

KVM is the virtualization component built into the Linux kernel, allowing Linux to operate as a hypervisor. In CVE-2026-64561, the flaw sits in KVM\/x86’s shadow memory management unit<\/em>, the mechanism responsible for managing shadow page tables during nested guest memory translation.<\/p>\n

According to the technical description, Zapscape is a check-ordering bug in the shadow MMU accounting path. While handling a page fault triggered by the guest, KVM may reclaim MMU pages and invalidate a shadow MMU root page that is still being used by the fault-handling thread. Because the path does not re-check the root after reclamation, KVM can continue operating under a stale root.<\/p>\n

This can lead to a use-after-free<\/em>: memory that has already been freed remains reachable through an old reference and is written again. The researcher said a proof of concept can build an exploitation chain that creates a root-owned file named \/Zapscape<\/code> on an affected KVM host.<\/p>\n

Impact and exploitation conditions<\/h2>\n

The key limitation is that the attacker needs kernel privileges inside the L1 guest. That does not make every Linux virtual machine an immediate target, but it increases the risk for infrastructure providers, multi-tenant systems, virtual machine rental environments, and any model that allows customers to run a nested hypervisor inside a VM.<\/p>\n

The Hacker News reported that the proof of concept targets AMD nested SVM\/NPT on Linux 7.1.3. QEMU is mentioned as a safe testing environment, but it is not the vulnerable component. The bug is in the kernel’s KVM code and can be triggered independently of QEMU’s emulation layer.<\/p>\n

Linux versions from 5.9 onward are listed as affected until a fixed stable release is applied, including milestones such as 6.6.148, 6.12.101, 6.18.42, 7.1.6, and 7.2-rc5. In practice, the status depends on each Linux distribution because vendors often backport security fixes without moving to the exact upstream version number.<\/p>\n

Disclosure timeline<\/h2>\n

According to the published timeline, the researcher reported the issue to security@kernel.org<\/code> on July 11, 2026. The patch was submitted and merged on July 21, then the issue was sent to the linux-distros list on August 1 under a five-day embargo. CVE-2026-64561 was assigned on August 4, and public disclosure followed on August 6.<\/p>\n

The upstream patch, merged in commit 2abd5287f083<\/code>, changes where the stale-root check is performed so that it happens after KVM calls make_mmu_pages_available()<\/code>. If reclamation invalidates the current root, KVM restarts the fault path with RET_PF_RETRY<\/code> instead of continuing to map or create a shadow page under a root that is no longer valid.<\/p>\n

What organizations should do<\/h2>\n

Administrators should prioritize reviewing KVM hosts with nested virtualization enabled, especially where guests are not fully trusted or are assigned to multiple user groups. The most important action is to update to a stable kernel or vendor package that has backported the fix for CVE-2026-64561.<\/p>\n

While waiting for a patch, organizations should limit exposure of nested virtualization to untrusted workloads, review policies that grant kernel-level control inside guests, isolate higher-risk lab environments, and track advisories from the Linux distribution in use. For virtualization service providers, host inventory by kernel version and backport status should come before any conclusion that the environment is safe.<\/p>\n

Zapscape again shows that the boundary between guest and host does not depend only on application-layer hypervisor configuration. It also depends directly on the correctness of the kernel itself. As nested virtualization expands across development and testing use cases, kernel patch management becomes a core part of infrastructure risk governance.<\/p>\n

VNCyberS<\/strong> compiled from The Hacker News and Linux Kernel<\/em><\/p>","protected":false},"excerpt":{"rendered":"

Zapscape, tracked as CVE-2026-64561, is a Linux KVM flaw affecting nested virtualization scenarios where an attacker with kernel privileges inside an L1 guest may be able to execute code on the Linux host.<\/p>","protected":false},"author":2,"featured_media":1897,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[1],"tags":[573,579,574,575,580,576,582,577,578,581,114,572],"class_list":["post-1899","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-tin-tuc","tag-cve-2026-64561","tag-kernel-security","tag-kvm","tag-linux-kernel","tag-linux-vulnerability","tag-nested-virtualization","tag-qemu","tag-shadow-mmu","tag-use-after-free","tag-virtualization-security","tag-vncybers","tag-zapscape"],"_links":{"self":[{"href":"https:\/\/vncybers.vn\/en\/wp-json\/wp\/v2\/posts\/1899","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/vncybers.vn\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/vncybers.vn\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/vncybers.vn\/en\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/vncybers.vn\/en\/wp-json\/wp\/v2\/comments?post=1899"}],"version-history":[{"count":1,"href":"https:\/\/vncybers.vn\/en\/wp-json\/wp\/v2\/posts\/1899\/revisions"}],"predecessor-version":[{"id":1900,"href":"https:\/\/vncybers.vn\/en\/wp-json\/wp\/v2\/posts\/1899\/revisions\/1900"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/vncybers.vn\/en\/wp-json\/wp\/v2\/media\/1897"}],"wp:attachment":[{"href":"https:\/\/vncybers.vn\/en\/wp-json\/wp\/v2\/media?parent=1899"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/vncybers.vn\/en\/wp-json\/wp\/v2\/categories?post=1899"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/vncybers.vn\/en\/wp-json\/wp\/v2\/tags?post=1899"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}