Zapscape (CVE-2026-64561) KVM guest escape and local root: mitigation and kernel update for CloudLinux

On August 6, 2026, researcher Hyunwoo Kim (@v4bel) publicly disclosed Zapscape, a use-after-free vulnerability in the Linux kernel’s KVM virtualization code. An attacker with root inside a KVM guest can use it to escape the guest and run code as root on the host. It follows Januscape, which Kim disclosed a month ago in the same part of the kernel. Zapscape is a separate bug.

The reach is wider than those who run virtual machines on KVM fleets. On CloudLinux 8, 8 LTS, 9, 9 LTS, and 10, the device file that lets a program create a virtual machine is readable and writable by every user on the server. A shell account or a compromised website can open it, build a throwaway guest, and attack the host kernel from inside that guest. Running shared hosting rather than a virtualization host is not, on its own, protection.

Two conditions can take a server out of scope. The attack needs the attacker’s guest to create a second guest inside itself, so a host with nested virtualization turned off cannot be reached this way. Intel processors older than Ice Lake-SP cannot be reached either.

 

What has and hasn’t been reproduced

Kim’s disclosure demonstrates a guest-to-host escape and ships a proof-of-concept that works against upstream kernels. It also lists two lesser outcomes: a host panic that takes down every guest on the machine, and local privilege escalation on hosts where the KVM device is world-writable.

Red Hat rates Zapscape Important, with a CVSS 3.1 score of 7.0, and describes the impact as instability and denial of service in virtualized environments rather than as a guest-to-host escape.

Based on our own testing, the published proof-of-concept does not run against CloudLinux-built kernels as written. In our reproduction it crashed the attacker’s own guest rather than the host, and we have not reproduced a guest-to-host escape on any CloudLinux kernel.

We are treating it as serious anyway. An exploit that does not run against our kernels today is not protection. The flaw is real and the code path is reachable. Adapting an exploit to a particular kernel is ordinary work for anyone motivated to do it, so apply the fix or a mitigation now rather than waiting to see whether a weaponized version appears.

 

Am I affected?

Three conditions have to hold together. If any one of them is false, the server is not exposed.

1. Can anything on this server use KVM? Either the host runs virtual machines, or ordinary users can open the KVM device directly.

ls -l /dev/kvm 2>/dev/null || echo "no /dev/kvm - module not currently loaded"

Mode 0666 (crw-rw-rw-) means every user on the server can open it. An absent device does not clear the server on its own: the KVM modules can load on demand when a program asks for them. That is why the mitigation below blocks loading rather than only unloading.

2. Is nested virtualization enabled? Nested virtualization means a guest can run a guest of its own.

# Live value, if the module is already loaded:
cat /sys/module/kvm_intel/parameters/nested 2>/dev/null      # kvm_amd on AMD hosts

# If that printed nothing the module is not loaded. Check what it will use when it loads:
modinfo kvm_intel 2>/dev/null | grep -i nested               # kvm_amd on AMD hosts

Y or 1 means enabled. The attack needs the attacker’s guest to create a second guest inside itself, so with nested virtualization off the chain cannot start.

3. Is the processor in scope? AMD hosts are in scope with no further condition. Intel hosts are only reachable where the host exposes both four-level and five-level Extended Page Tables (EPT) to guests, which means Ice Lake-SP and newer.

# Intel hosts only:
grep -w ept_5level /proc/cpuinfo

On an Intel host, no output means this condition is not met and the server is not exposed by that route.

Affected CloudLinux versions

The table shows whether each attack path is open on a given version. It does not say whether a particular server is exposed: both paths still require conditions 2 and 3 above.

Version	Affected	Status
CloudLinux 7 (CL7) Kernel 3.10	✅ Not affected. The 3.10 kernel does not carry the Linux 5.9 rule that makes the flaw exploitable.	—
CloudLinux 7h (CL7h) Kernel 4.18	⚠️ Via a guest: only if this host runs VMs ✅ Via a local user: no, /dev/kvm is restricted	✅ Kernel: in beta, rolling to stable ⏳ Livepatch: in preparation
CloudLinux 8 (CL8) Kernel 4.18	⚠️ Via a guest: only if this host runs VMs ❌ Via a local user: yes, /dev/kvm open to all	✅ Kernel: in beta, rolling to stable ⏳ Livepatch: in preparation
CloudLinux 8 LTS Kernel 4.18 (TuxCare ELS)	⚠️ Via a guest: only if this host runs VMs ❌ Via a local user: yes, /dev/kvm open to all	⏳ Kernel: in preparation ⏳ Livepatch: in preparation
CloudLinux 9 (CL9) Kernel 5.14	⚠️ Via a guest: only if this host runs VMs ❌ Via a local user: yes, /dev/kvm open to all	✅ Kernel: available now ⏳ Livepatch: in preparation
CloudLinux 9 LTS Kernel 5.14 (TuxCare ELS)	⚠️ Via a guest: only if this host runs VMs ❌ Via a local user: yes, /dev/kvm open to all	⏳ Kernel: in preparation ⏳ Livepatch: in preparation
CloudLinux 10 (CL10) Kernel 6.12	⚠️ Via a guest: only if this host runs VMs ❌ Via a local user: yes, /dev/kvm open to all	⏳ Kernel: in preparation ⏳ Livepatch: in preparation
CloudLinux for Ubuntu 22.04 LTS Kernel 5.15	⚠️ Via a guest: only if this host runs VMs ⚠️ Via a local user: kvm group members only	⏳ Kernel: via Canonical † ⏳ Livepatch: in preparation

^† CloudLinux for Ubuntu 22.04 runs the stock Ubuntu kernel, so its kernel fix arrives from Canonical rather than from a CloudLinux stream. The KernelCare livepatch is the CloudLinux-side path on that platform.

A KernelCare livepatch is in preparation for every affected version and installs without a reboot. See Stream 4 for current status.

 

Is there a mitigation?

Yes. Which one applies depends on whether the server runs virtual machines.

If this server runs no virtual machines

Most shared-hosting servers are in this group, and for them the fix is cheap: unload the KVM modules and block them from loading again. This closes both attack paths and needs no reboot.

sudo modprobe -r kvm_intel kvm_amd kvm 2>/dev/null

Read the result before continuing. “Module not found” or “not currently loaded” means KVM is not active on this host, which is the expected outcome on a shared-hosting server. Continue to the block below. “Module is in use” means something is holding KVM open, usually a running guest, so use the next section instead.

Then block loading at boot:

printf 'install kvm_intel /bin/falseninstall kvm_amd /bin/falsen' 
  | sudo tee /etc/modprobe.d/disable-kvm.conf

The filename is the same one the Januscape advisory used. If you applied this during Januscape and left it in place, this path is already closed and you need to do nothing here.

Check it took: lsmod | grep kvm returns nothing, and ls /dev/kvm reports no such file or directory.

To revert after installing a patched kernel, delete /etc/modprobe.d/disable-kvm.conf and run sudo modprobe kvm_intel, or reboot.

If this server runs virtual machines

Disable nested virtualization. The attack needs a guest to create a guest of its own. Turning nested virtualization off removes that step, and ordinary single-level guest workloads do not need it.

First read the current live value, because the setting below only takes effect after a module reload:

cat /sys/module/kvm_intel/parameters/nested      # kvm_amd on AMD hosts

Then write the setting. On an Intel host:

echo 'options kvm_intel nested=0' | sudo tee /etc/modprobe.d/zapscape.conf

On an AMD host:

echo 'options kvm_amd nested=0' | sudo tee /etc/modprobe.d/zapscape.conf

Compatibility. The module parameter is read when the module loads. Applying it means unloading and reloading kvm_intel or kvm_amd, which requires stopping every running guest: in practice a scheduled drain or a host reboot.

Do not apply it at all on hosts where nested virtualization is sold or relied on:

• nested hypervisor tenants
• continuous-integration runners that boot their own virtual machines
• Windows guests using virtualization-based security
• virt-install inside a guest

Note what this costs. Disabling nested virtualization needs the same guest drain that installing a patched kernel needs, and it leaves the flaw in place. If you are taking the outage either way, install the patched kernel instead where one is available for your version.

Restrict the KVM device. This closes the local-user path. It does nothing against a guest tenant, so on a virtualization host it is a partial measure rather than a fix.

echo 'KERNEL=="kvm", GROUP="kvm", MODE="0660"' | sudo tee /etc/udev/rules.d/65-kvm.rules
sudo udevadm control --reload-rules
sudo udevadm trigger /dev/kvm

Add users who legitimately need KVM to the kvm group with usermod -aG kvm <user> rather than putting the mode back to 0666. This is the same rule file the Januscape advisory used, so servers that still carry it need no change.

 

Update instructions

Four delivery streams cover the affected platforms.

Stream 1 — CloudLinux kernel (CloudLinux 7h, CloudLinux 8)

To install from the beta channel now, on CloudLinux 8:

yum update 'kernel*' --enablerepo=cloudlinux-updates-testing
reboot

On CloudLinux 7h:

yum update 'kernel*' --enablerepo=cl7h_beta
reboot

Once the kernels reach the stable channel, a plain yum update kernel; reboot is enough.

Stream 2 — AlmaLinux kernel (CloudLinux 9, CloudLinux 10)

On CloudLinux 9, the fix is a standard update with no testing repository needed:

dnf update 'kernel*'
reboot

Stream 3 — TuxCare ELS kernel (CloudLinux 8 LTS, CloudLinux 9 LTS)

Once the package is released, ELS-subscribed customers install it from the TuxCare ELS repository.

yum update kernel-lts
reboot

Stream 4 — KernelCare livepatch (all affected versions)

To deploy from the testing feed once it is available:

kcarectl --update --prefix test

Once promoted to the main feed, subscribed servers receive the patch automatically on the next update cycle, or on demand:

kcarectl --update

 

How to verify you are patched

Kernel streams (1, 2, and 3). After updating and rebooting, compare the running kernel against the target version listed in the status callout for your platform’s stream.

uname -r

KernelCare (Stream 4). Check the patch build date and the CVE.

kcarectl --info | grep kpatch-build-time      # build dated 2026-08-06 or later
kcarectl --patch-info | grep 'CVE-2026-64561'

 

Why this matters

On a host that runs virtual machines

The attacker is a compromised tenant. On a server selling VPS instances the paying customer already has root inside their own guest, because that is what they bought.

From there the chain is short. The tenant drives the vulnerable code path in the host kernel and, where the escape works, ends up with root on the hypervisor instead of only in their own guest. Root on the hypervisor reaches the memory, disk images, and network state of every other guest on the machine: files, databases, credentials, backups.

On a patched host, or one carrying the livepatch, that step fails. A hostile tenant stays inside the VPS.

If you run shared hosting and no virtual machines

The attacker is whoever compromised one of the sites you host. A vulnerable plugin is enough to put code on the server running as a site user.

On CloudLinux 8, 8 LTS, 9, 9 LTS, and 10 that user can open /dev/kvm, because the device is world-writable by default. They build a small guest of their own, which makes them root inside it without ever touching your accounts, and then use that guest as the platform to attack the host kernel.

The payoff of patching is measured in what an incident costs. A compromised site that stays a compromised site is one account to clean up. A compromised site that becomes root on the host is a server to rebuild and a data breach conversation with every customer on it.

 

Technical details of the bug

KVM keeps shadow page tables: the host’s own copy of the page tables a guest believes it is using. When memory runs short, the kernel reclaims shadow pages to stay inside a quota. Zapscape is a use-after-free in that reclamation path.

The ordering was wrong. In both of KVM’s x86 page-fault handlers, the kernel checked whether a page fault had gone stale before it made shadow pages available, rather than after. If reclamation zapped the root the fault was working on, that root was marked invalid. The kernel then mapped memory into it anyway. Child pages inherited the invalid state from the parent and ended up on the list of active pages, which is precisely what that list is supposed to never hold, and the recursive reclamation path then walked structures that had already been freed.

Reaching it takes two levels of nesting above the host. The host is the target. The attacker’s guest sits above it, and that guest boots a guest of its own. The attacker’s guest switches memory modes to alias shadow pages, and then the innermost guest’s memory activity drives the host into reclaiming shadow pages while the outer guest’s root is still in use.

This is why nested virtualization is a requirement rather than a detail. A single-level guest on modern hardware is handled by the processor’s own nested paging, EPT on Intel and Nested Page Tables (NPT) on AMD, and never enters this code at all. Shadowing a guest that is itself running a guest is what forces the host back into it.

The processor asymmetry comes from the same place. On AMD there is no additional condition. On Intel the path is only reachable when the host exposes both four-level and five-level EPT to the guest, which means Ice Lake-SP and newer.

The mis-ordering dates to 2008, and it was harmless for 12 years. Linux 5.9 added the rule that invalid shadow pages must never go back on the list of active pages, and that rule is what the stale check, running too early, violates. Kernels from 5.9 up to the fix carry it. Red Hat backported that rule into its 4.18 kernel, which is why CloudLinux 7h, 8, and 8 LTS are affected despite carrying a lower version number than 5.9.

The fix is a reordering and nothing more: move the stale-root check to after shadow pages are made available, in both fault handlers.

 

References

• Public disclosure (oss-security), Hyunwoo Kim (@v4bel), August 6, 2026: oss-security archive
• Proof-of-concept and write-up: V4bel/Zapscape on GitHub
• Upstream fix, commit 2abd5287f083
• The commit that introduced the rule, f95eec9bed76 (Linux 5.9)
• Red Hat: CVE-2026-64561
• National Vulnerability Database (NVD): CVE-2026-64561 (no severity score assigned at time of publication)
• Prior advisory: Januscape (CVE-2026-53359)
• CloudLinux status page: Zapscape incident