Correcting the scope of this issue and adding mitigation and update instructions.
Who is exposed. This is not limited to servers that run virtual machines. On CloudLinux 8, 8 LTS, 9, 9 LTS and 10 the /dev/kvm device is mode 0666, so any local user, or a compromised website running as a site user, can create a throwaway guest of their own and attack the host kernel from inside it. Running shared hosting rather than a virtualization host is not, on its own, protection. On CloudLinux 7h the device is restricted, and on CloudLinux for Ubuntu 22.04 it is open to members of the kvm group only.
Am I affected. Three conditions have to hold together, and if any one is false the server is not exposed.
1. Something on this server can use KVM, either a running guest or an openable device. An absent device does not clear the server, because the modules load on demand when a program asks for them. ls -l /dev/kvm
2. Nested virtualization is enabled. Use kvm_amd on AMD hosts. Y or 1 means enabled. cat /sys/module/kvm_intel/parameters/nested
3. The processor is in scope. AMD hosts are in scope with no further condition. Intel hosts are reachable only where five-level EPT is exposed to guests, which means Ice Lake-SP and newer. No output on an Intel host means that route is closed. grep -w ept_5level /proc/cpuinfo
Affected CloudLinux versions. - CloudLinux 7: not affected. The 3.10 kernel does not carry the Linux 5.9 rule that makes the flaw exploitable. - CloudLinux 7h: kernel in beta, rolling to stable. Livepatch in preparation. - CloudLinux 8: kernel in beta, rolling to stable. Livepatch in preparation. - CloudLinux 8 LTS: ELS kernel and livepatch in preparation. - CloudLinux 9: kernel available now. Livepatch in preparation. - CloudLinux 9 LTS: ELS kernel and livepatch in preparation. - CloudLinux 10: kernel and livepatch in preparation. - CloudLinux for Ubuntu 22.04: kernel arrives from Canonical. Livepatch in preparation.
Mitigation. Which one applies depends on whether the server runs virtual machines.
If it runs none, which is most shared hosting, unload the KVM modules and block them from loading again. This closes both attack paths and needs no reboot. modprobe -r kvm_intel kvm_amd kvm printf 'install kvm_intel /bin/false\ninstall kvm_amd /bin/false\n' | tee /etc/modprobe.d/disable-kvm.conf This is the same file the Januscape advisory used. If you applied it then and left it in place, this path is already closed and there is nothing to do here.
If it does run virtual machines, disable nested virtualization. On Intel: echo 'options kvm_intel nested=0' | tee /etc/modprobe.d/zapscape.conf On AMD: echo 'options kvm_amd nested=0' | tee /etc/modprobe.d/zapscape.conf The parameter is read when the module loads, so applying it means a guest drain or a host reboot. Do not apply it where nested virtualization is sold or relied on. Restricting the device closes the local-user path only, not the guest path. echo 'KERNEL=="kvm", GROUP="kvm", MODE="0660"' | tee /etc/udev/rules.d/65-kvm.rules
Patched kernels. CloudLinux 7h and CloudLinux 8 are in the beta channel and rolling out to stable. - CloudLinux 7h: kernel-4.18.0-553.150.1.lve.el7h or newer - CloudLinux 8: kernel-4.18.0-553.150.1.lve.el8 or newer
To install from beta on CloudLinux 8, and use --enablerepo=cl7h_beta on CloudLinux 7h: yum update 'kernel*' --enablerepo=cloudlinux-updates-testing reboot
CloudLinux 9 is fixed in AlmaLinux stable as kernel-5.14.0-687.30.1.el9_8 or newer, released July 22, 2026. No testing repository needed. dnf update 'kernel*' reboot
The CloudLinux 10 kernel is in preparation. The patched kernel-lts for CloudLinux 8 LTS and CloudLinux 9 LTS is in preparation on the TuxCare ELS pipeline, which is separate from the stock CloudLinux 8 and 9 rebuild, and target versions will be posted on release.
KernelCare. Livepatches are in preparation across the affected platforms and feed availability will be posted here as builds ship.
How to verify. For a kernel update, compare the running kernel against the target version for your platform with uname -r. For the livepatch, once it ships, use --patch-info. The kcarectl --info form returns empty output even on a correctly patched system. kcarectl --patch-info | grep 'CVE-2026-64561'
On the public exploit. The proof-of-concept works against upstream kernels, but it does not run against CloudLinux-built kernels as written. In our own testing 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. Red Hat describes the impact as instability and denial of service in virtualized environments rather than as an escape. We are treating it as serious anyway, because the flaw is real, the code path is reachable, and adapting an exploit to a particular kernel is ordinary work for anyone motivated to do it.
Full advisory, with the affected-version table and per-stream update instructions: Zapscape (CVE-2026-64561) on the CloudLinux blog. This page and the advisory are updated as patches are released.
Posted Aug 07, 2026 - 10:54 UTC
Identified
We are aware of CVE-2026-64561, a Linux-kernel KVM/virtualization flaw disclosed publicly on 2026-08-04 under the branded name "Zapscape" and characterized as a guest-to-host escape. It carries a severity of Important (CVSS 7.0, by Red Hat). Systems that run virtual machines via KVM are the relevant population; systems that do not use KVM are not exposed by this issue.
Current Status: The upstream fix was shipped for EL8 and EL9 in the 8.10 and 9.8 kernels on July 22-23, attributed to a different CVE. Current kernels 8.10 (4.18.0-553.147.1+) or 9.8 (5.14.0-687.30.1+) already have the fix. Other versions are presumed affected. EL10 remains vulnerable. Ubuntu distros are likely to be vulnerable as well.
KernelCare patches are in progress.
Posted Aug 06, 2026 - 22:32 UTC
This incident affects: CloudLinux OS Components (CloudLinux Kernel).