Januscape (CVE-2026-53359): Mitigation and Kernel Update on CloudLinux

On July 6, 2026, researcher Hyunwoo Kim (@v4bel) publicly disclosed Januscape, a vulnerability in the Linux kernel’s KVM/x86 memory-management code. It has two attack paths. A malicious virtual machine can break out of the guest and run code as root on the host it runs on. And on any host where the KVM device node /dev/kvm is world-accessible, which is the default on EL8 and later, an unprivileged local user can trigger the same bug directly to crash the host, with a working root-level exploit reported but not yet public. Kim is the researcher behind the earlier KVM/arm64 escape “ITScape” (CVE-2026-46316); Januscape is its x86 sibling.

What the bug is

Januscape is a race condition in the KVM x86 memory-management unit (arch/x86/kvm/mmu/mmu.c). Under the race, the host associates a shadow page-table entry with the wrong guest frame number: a frame-number and type confusion in host-managed page tables. Steered carefully, that mis-mapping lets a guest drive the host into mapping memory the attacker chooses, which is how the guest-to-host escape is built. Run without that steering, the same race trips the kernel’s own consistency checks and takes the host down (pte_list_remove). The bug triggers on both Intel (VMX/EPT) and AMD (SVM/NPT) processors.

The defect is old. It was introduced in 2010 and fixed upstream on June 16, 2026, which means nearly every Linux kernel shipped in the last 16 years carries it. Fixing Januscape takes two coupled upstream patches, and both are required: commit 81ccda30b4e8 (CVE-2026-53359, the escape fix) and its companion 0cb2af2ea66a (CVE-2026-46113, the frame-number fix).

A public proof-of-concept is available. It demonstrates the host-crash path: a guest loads a module that seizes raw virtualization state and races the host into a panic within seconds to minutes. The disclosure indicates a full root-level guest-to-host exploit exists but has not been released publicly. In our own testing we have reproduced the crash and the underlying memory corruption.

Details: oss-security disclosure · upstream fix (commit 81ccda30b4e8) · januscape.io · NVD entry for CVE-2026-53359

Affected CloudLinux versions

Legend: ✅ not exposed · ⚠️ conditional exposure · ❌ exposed by default.

TuxCare ELS customers on CloudLinux 8 LTS and CloudLinux 9 LTS are patched through the ELS kernel-lts package (see Stream 3). A KernelCare livepatch is available as a no-reboot alternative on all affected versions.

Apply this mitigation now

Whether a mitigation applies depends on whether the server runs KVM guests.

If the server does not run virtual machines (most shared-hosting servers)

Remove the attack surface entirely by unloading the KVM modules and blocking them from loading. This closes both attack paths and does not require a reboot.

# Unload now. This fails if a VM is running, which means the host runs guests; see the next section instead.
sudo modprobe -r kvm_intel kvm      # use kvm_amd on AMD hosts

# Prevent loading on boot. "install ... /bin/false" also blocks dependency and explicit loads,
# which a plain "blacklist" line does not.
printf 'install kvm_intel /bin/false\ninstall kvm_amd /bin/false\n' \
  | sudo tee /etc/modprobe.d/disable-kvm.conf

Verify the surface is gone: lsmod | grep kvm returns nothing, and ls /dev/kvm reports “No such file or directory.”

To revert after the patched kernel is installed, remove /etc/modprobe.d/disable-kvm.conf and run sudo modprobe kvm_intel (or reboot).

If the server is a KVM hypervisor (runs guests)

You cannot unload the KVM modules on a host that is running guests. You can close the unprivileged-local-user path by restricting /dev/kvm to root and the kvm group, so that only legitimate virtualization users can open it:

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

After this change, a process that opens /dev/kvm without root privileges or kvm-group membership fails with EACCES. Add legitimate users to the group with usermod -aG kvm the_user.

This does not stop the guest-to-host escape. A malicious guest still triggers the bug from inside its own VM regardless of device permissions. For a hypervisor host, the patched kernel or a KernelCare livepatch is the only complete fix. Install the patched kernel (Stream 1, 2, or 3) or the KernelCare livepatch (Stream 4) as soon as it is available for your platform.

Update instructions

Four delivery streams cover the affected platforms.

Stream 1 — CloudLinux kernel (CL7h, CL8)

To install from the beta/testing channel now (CL8):

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

For CL7h:

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

Stream 2 — AlmaLinux kernel (CL9, CL10)

To install from the AlmaLinux testing repository now, enable it by installing the release-testing package directly from the AlmaLinux repo, update the kernel, then disable the testing repo again.

For CL10:

dnf install -y https://repo.almalinux.org/almalinux/10/extras/x86_64/os/Packages/almalinux-release-testing-10-2.el10.x86_64.rpm
dnf update 'kernel*'
reboot
dnf config-manager --disable almalinux-testing

For CL9:

rpm -Uvh --nodeps https://repo.almalinux.org/almalinux/9/extras/x86_64/os/Packages/almalinux-release-testing-9-2.el9.noarch.rpm
dnf update 'kernel*'
reboot
dnf config-manager --disable almalinux-testing

Once the kernels reach the production repositories, a plain dnf update kernel; reboot is sufficient.

Stream 3 — TuxCare ELS LTS kernel (CL8 LTS, CL9 LTS)

ELS-subscribed customers install from the TuxCare ELS repository. This pipeline is separate from the stock CL8/CL9 kernel rebuild above.

yum update kernel-lts
reboot

Stream 4 — KernelCare livepatch (all affected versions)

To deploy from the testing feed:

kcarectl --update --prefix test

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

kcarectl --update

How to verify you are patched

Streams 1, 2, and 3 (kernel update). After updating and rebooting, compare your running kernel against the target version in the relevant stream’s most recent status callout above:

uname -r

Stream 4 (KernelCare). Both fixes are required for Januscape, so check for both:

kcarectl --patch-info | grep -E 'CVE-2026-53359|CVE-2026-46113'

References

• Public PoC — github.com/V4bel/Januscape
• Public disclosure (oss-security)
• Upstream escape fix — commit 81ccda30b4e8 (CVE-2026-53359)
• Upstream companion fix — commit 0cb2af2ea66a (CVE-2026-46113)
• AlmaLinux advisory — Januscape and Bad epoll
• NVD entry — CVE-2026-53359