Zapscape Breaks the Linux KVM Boundary. A Server Without a Single VM Can Still Be in Range.

The economics of VPS and cloud hosting rest on a single promise: many customers can share one physical machine because the hypervisor keeps each of them sealed inside their own virtual machine. Zapscape breaks that seal. Disclosed on August 6, 2026 and tracked as CVE-2026-64561, it is a use-after-free flaw in the KVM hypervisor built into the Linux kernel. An attacker who already holds root inside a guest can escape to the host and run code there as the host’s own kernel.

On a multi-tenant server that means one customer breaking out of their box and standing as root over everyone else’s. It is not, however, a CloudLinux flaw, and CloudLinux’s own advisory says so plainly: Zapscape is an upstream kernel bug that reaches several Linux distributions. Red Hat rates it Important for its own products, and Debian’s security tracker listed bullseye, bookworm and trixie as vulnerable on disclosure day. Kim warns it can threaten multi-tenant public clouds even where they run their own virtualization stack.

For hosting operators the most consequential view of it still runs through CloudLinux, whose kernels sit under a large share of the world’s shared-hosting and reseller infrastructure. CloudLinux has published a version-by-version advisory, is shipping patched kernels and has documented mitigations for the gap in between. Two things make this worth more than a routine patch note. It is the third KVM escape the same researcher has published since June, and the second in this exact part of the kernel in a month. And on most CloudLinux versions, a server does not need to run virtual machines at all to be in range.

Key facts (advisory status checked August 10, 2026)

• What it is. Zapscape (CVE-2026-64561) is a use-after-free in KVM’s x86 shadow memory management unit. The kernel checked whether a page fault had gone stale before it reclaimed shadow pages instead of after, so KVM kept building memory mappings underneath a root it had already invalidated.
• What it gives an attacker. Kernel-level privilege inside a guest (usually guest root) turns into code execution on the host as root, which on shared hardware exposes every other tenant on the box.
• Two ways in. On a host that runs virtual machines, a tenant with root in their own guest reaches the host. On a shared-hosting server running no virtual machines, an ordinary user or a compromised website can create a throwaway guest of their own and attack the host kernel from inside it, wherever /dev/kvm is world-writable.
• What both paths need. Nested virtualization enabled, plus the right processor. On AMD, every processor qualifies; on Intel it needs Ice Lake-SP or newer, where both four-level and five-level EPT page walking is exposed to the guest.
• Who found it. Security researcher Hyunwoo Kim, who goes by v4bel. It is his third KVM escape since June, after ITScape (CVE-2026-46316) on arm64 and Januscape (CVE-2026-53359) in this same x86 code a month ago. A public proof-of-concept exists, demonstrated against AMD nested virtualization on Linux 7.1.3.
• Severity, and it is disputed. Red Hat rates it Important with a CVSS 3.1 base score of 7; cve.org scores the same flaw 8.8. The gap comes from two vector choices: attack complexity and whether the scope changes. NVD has not scored it. Red Hat classifies the weakness as CWE-825, expired pointer dereference.
• Exploitation. No in-the-wild exploitation is confirmed. Kim describes his own published code as not immediately usable against real cloud environments, and CloudLinux notes it does not run against CloudLinux-built kernels as written. Neither statement is protection, only a delay.
• The impact itself is contested. Kim documents a chain ending in host code execution. TuxCare says its own testing has not reproduced the full escape on any CloudLinux-built kernel, observing only a crash of the attacker’s own guest, and Red Hat’s wording describes instability and denial of service. TuxCare’s summary: treat the escape as credible, not as a demonstrated fleet-wide compromise.
• Not a CloudLinux-only problem. Zapscape is an upstream Linux kernel bug that reaches every distribution shipping an affected kernel. Debian’s tracker listed bullseye, bookworm and trixie as vulnerable at disclosure, and Kim warns it can threaten multi-tenant public clouds running their own virtualization stacks. CloudLinux gets the detailed treatment below because of how widely its kernels are used in shared hosting.
• Affected CloudLinux kernels. CloudLinux 7h and 8 (4.18), 9 (5.14), 10 (6.12), the 8 LTS and 9 LTS lines under TuxCare ELS, and CloudLinux for Ubuntu 22.04 (5.15). CloudLinux 7 (3.10 kernel) is not affected, because its kernel does not carry the Linux 5.9 validation rule that makes the flaw exploitable.
• The fix, and how far it has got. CloudLinux 9 is available now in kernel-5.14.0-687.30.1.el9_8 or newer. CloudLinux 7h and 8 are still in the beta channel, rolling out to stable, targeting kernel-4.18.0-553.150.1.lve. CloudLinux 10, the TuxCare ELS lines and the KernelCare livepatch remain in preparation.

How Guest Root Becomes Host Root

KVM keeps a guest’s view of memory separate from the host using structures called shadow pages, and it constantly reclaims old ones to make room for new mappings as the guest runs. The bug lives in the ordering of two steps during that housekeeping. When a guest triggers a page fault, KVM checks whether the fault has gone stale, meaning the memory it referred to has already been torn down, and it also reclaims shadow pages to free capacity. Zapscape is what happens when those two steps run in the wrong order. KVM validated the shadow root before reclaiming pages rather than after. Reclamation could therefore invalidate the very root the fault handler was still using, and the handler kept mapping memory beneath a structure that had already been freed. An attacker inside the guest steers that use-after-free into corrupting the host kernel’s own shadow pages, and from there into running code on the host.

The mistake is old. The flawed ordering dates to 2008. It only became reachable as a security flaw once Linux 5.9 introduced stricter validation rules in 2020, which is why kernels that never received that rule, including CloudLinux 7’s 3.10 base, are untouched. The 4.18 kernels in CloudLinux 7h, 8 and 8 LTS are affected despite their lower version number because Red Hat backported the rule into its 4.18 line. The upstream fix, merged as commit 2abd5287f083 on July 21, 2026, is small and precise. It moves the stale-root check to after the reclamation step. If reclaim has invalidated the current root, KVM now restarts the fault cleanly instead of building on freed memory.

The Attacker Can Supply Their Own Guest

The obvious reading is that this only concerns virtualization hosts. It does not, and the reason is worth spelling out. The attack needs a guest to work from, but on a plain shared-hosting box the attacker can supply that guest themselves. An ordinary user account, or a compromised website, is enough to spin up a throwaway virtual machine and mount the escape from inside it. No tenant VMs need exist on the server beforehand.

What decides whether that is possible is a permissions question rather than an architectural one: whether the /dev/kvm device is reachable by ordinary users. CloudLinux ships that differently across its versions, which is why two servers running the same workload can sit on opposite sides of this. Nor is the open default a CloudLinux quirk. Kim notes that on distributions such as RHEL, /dev/kvm is world-writable out of the box, turning the flaw into a route from an unprivileged local account to root there as well.

Both paths still need nested virtualization enabled, the arrangement where a guest can run guests of its own, because the vulnerable shadow-MMU path is the one KVM falls back to in that scenario. That sounds like a narrow condition and is not. It turns up in continuous-integration runners that boot their own virtual machines, in Windows guests using virtualization-based security, in customer VMs that run their own hypervisor or emulator, and in any cloud-inside-a-cloud arrangement a reseller might offer. More to the point, upstream KVM has enabled nesting by default on both Intel and AMD since Linux 4.20, so the safe assumption is that it is on unless someone deliberately turned it off. TuxCare’s advice is to read the module parameter rather than trust the assumption.

The processor detail decides how wide the exposure runs. On AMD hardware there is no extra condition beyond nested virtualization, so every AMD-based host that exposes nesting is in range. On Intel the requirement is narrower: the host must be Ice Lake-SP or newer and expose both four-level and five-level EPT page walking to the guest. For a provider taking inventory, the blunt version is that AMD fleets should assume they are exposed everywhere nesting is on, while Intel fleets can scope the risk to their newer silicon.

Which CloudLinux Version You Run Decides How Bad This Is

The table below is the fastest way to place your own fleet. It shows whether each attack path is open on a given version and where the fix stands. It does not say whether a particular server is exposed, because both paths still require nested virtualization and a qualifying processor.

The pattern is worth stating plainly: the local-user path is open on five of the eight lines and closed only on CloudLinux 7h, with Ubuntu 22.04 restricting it to members of the kvm group and CloudLinux 7 out of scope entirely. A shared-hosting operator on CloudLinux 8, 9 or 10 cannot dismiss this as a virtualization problem.

The Third KVM Escape From the Same Researcher Since June

Zapscape does not arrive in isolation, and Kim does not pretend otherwise. He publishes it as the closing part of what he calls the KVM Escape Trilogy: ITScape (CVE-2026-46316), an arm64 escape published in June; Januscape (CVE-2026-53359), disclosed in July in the same x86 shadow-MMU code; and now Zapscape. Januscape and Zapscape are separate bugs of the same family, both letting a guest reach the host on Intel and AMD alike.

Three guest-to-host escapes from one researcher in three months is a signal about where the pressure is landing. The shadow MMU is legacy code that most modern hosts sidestep with hardware nested paging, right up until nested virtualization drags execution back into it, and that is exactly the corner these bugs keep surfacing in. For a hosting operator the lesson is not to treat any of them as a one-off. If Januscape prompted an emergency reboot cycle in July, Zapscape belongs to the same category of risk and largely the same population of machines, and the reasonable assumption is that this seam will keep producing findings.

The exploitation picture is a mix of reassurance and warning, and it is worth reading both halves. There is no confirmed use in the wild. CloudLinux observes that the public proof-of-concept, which targets AMD nested virtualization on Linux 7.1.3, does not run against CloudLinux-built kernels as written. Kim goes further about his own code, describing it as “not a weaponized exploit that runs immediately” in cloud environments. Real-world use would mean moving the first-level actions into a guest kernel module, then adapting the exploit to the host’s kernel configuration and memory backend.

There is a larger disagreement underneath, and it is worth stating plainly because two very different descriptions of Zapscape are in circulation. Kim documents a chain that ends in host kernel code execution from inside a guest. TuxCare, CloudLinux’s own security arm, says its testing has not reproduced that full escape on any CloudLinux-built kernel. What it observed instead was a crash of the attacker’s own first-level guest, which is a denial of service against their machine rather than a compromise of the host. Red Hat’s wording points the same way, framing the impact as instability in virtualized environments.

TuxCare’s own summary is the fairest reading available: treat the escape as credible rather than demonstrated. That is not permission to wait. A proof-of-concept that needs adjusting buys time rather than safety, public exploit code alongside a precise upstream patch is the recipe by which a working attack becomes available quickly, and nobody disputes that the virtualization boundary is broken. The clock is running, even if the worst case has not yet been shown on a production kernel.

The Fixed Kernels, and the Stopgaps for Everyone Else

The durable fix is a patched kernel and a reboot into it, and the rollout is partway through. CloudLinux 9 is available now, in kernel-5.14.0-687.30.1.el9_8 or newer. CloudLinux 7h and 8 are in the beta channel and rolling out to stable, targeting kernel-4.18.0-553.150.1.lve or newer, so an operator checking today may not find it in the stable stream yet. Still in preparation: CloudLinux 10, the 8 LTS and 9 LTS lines under TuxCare Extended Lifecycle Support, and a KernelCare livepatch that closes the hole without a reboot. CloudLinux 7 on the 3.10 kernel needs nothing, since it never received the rule that makes the flaw exploitable.

Outside the CloudLinux world the fix arrives through each distribution’s normal kernel updates. The National Vulnerability Database lists Linux 5.9 and later as affected, with fixes landing in stable releases including 6.6.148, 6.12.101, 6.18.42, 7.1.6 and 7.2-rc5; on disclosure day Debian carried a fixed kernel only in sid. Anyone running a distribution kernel rather than a CloudLinux one should check their vendor’s advisory against those numbers.

Until a patched kernel is installed and the machine has rebooted into it, there are real stopgaps, and which one fits depends on what the server actually does:

• Server runs no virtual machines. Unload the KVM modules and block them from loading through a file in /etc/modprobe.d/. It takes effect without a reboot and removes the vulnerable code from play entirely. This is the common shared-hosting case and the cleanest fix available before the kernel lands
• Server is a virtualization host. Unloading is not an option, so disable nested virtualization through the kvm_intel or kvm_amd module parameters. This one needs a module reload, which means draining guests or rebooting
• Either case, as hardening only. Restricting permissions on /dev/kvm through a udev rule narrows the local-user path but is a partial measure, not a fix

The priority order sorts itself by role. If untrusted customers can run nested guests on AMD hardware, this is an emergency patch cycle. If you run stock shared hosting with no virtual machines, block the module today and schedule the kernel update without the adrenaline. Either way, confirm the running kernel version afterward rather than trusting that the update took.