Nowedays, cloud computing mainly remains on virtualization. Public cloud providers, enterprise virtualization platforms, and countless self-hosted infrastructures rely on the Linux Kernel-based Virtual Machine (KVM) to isolate guest virtual machines from their hosts.
This isolation is one of the most important security guarantees offered by virtualization and crossing that boundary, could have severe consequences.
On July 6 2026, security researcher Hynunwoo Kim (V4bel) disclosed Januscape (CVE-2026-53359), a critical vulnerability affecting KVM/x86 systems. In June, he disclosed ITScape (CVE-2026-46316), the first guest-to-host escape on KVM/arm64, exploiting a race condition in the virtual interrupt controller. The flaw allows a guest VM to corrupt memory in the host kernel and potentially execute arbitrary code with kernel privileges. Although the public PoC currently demonstrated a reliable host crash, the researcher reports that separate, unreleased exploit achieves full guest-to-host escape with host root privileges.
What is Januscape ?
Januscape is a use-after-free (UAF) vulnerability located in the shadow MMU (Memory Management Unit) implementation of KVM on x86 processors.
Unlike vulnerabilities affecting QEMU or userspace virtualization software, Januscape exists directly inside the Linux kernel's KVM subsystem. As a result, exploitation targets the hypervisor itself rather than a user-space process.
The vulnerability affects both Intel VT-x and AMD-V systems because both architectures share the vulnerable shadow MMU implementation.
How it works ?
Shadow MMU
Under normal circumstances, modern processors use hardware-assisted virtualization features such as:
- Intel EPT (Extended Page Tables)
- AMD NPT (Nested Page Tables)
These technologies significantly reduce the amount of memory virtualization that must be performed by the hypervisor.
However, when nested virtualization is enabled (allowing a virtual machine to itself run virtual machines), KVM must frequently fall back to its legacy shadow page table implementation.
It is inside this compatibility layer that Januscape exists.
The bug
The vulnerability originates from incorrect reuse of shadow MMU pages.
When KVM attempts to recycle previously allocated shadow pages, it verifies only part of the page's identity before reusing it. Under specific circumstances, two pages may share the same guest frame number (GFN) while representing different MMU roles.
This mismatch allows a stale page to be reused after it has already been freed.
An attacker controlling the guest can repeategly manipulate page mappings until KVM eventually accesses memory that has already been released.
This classis use-after-free condition results in corruption of kernel memory.
Depending on how the corrupted structures are reused, this may lead to:
- Kernel Panic
- Arbitrary kernel memory corruption
- Potential execution of attacker-controlled code within the host kernel
Why Nested Virtualization matters
A key characteristic of Januscape is that it is only reachable when nested virtualization is exposed to guest virtual machines.
Although most virtualization deployments normally rely on hardware-assisted paging (EPT/NPT), nested virtualization forces KVM to exercise the vulnerable shadow MMU code path.
For many public cloud environments this feature is intentionally enabled so customers can run Kubernetes clusters, Android emulators, CI systems, or their own hypervisors inside virtual machines.
This makes nested virtualization particularly attractive for attackers.
Mitigation
Update your kernel
The vulnerability has already been fixed upstream and backported to supported stable kernel branches. Administrators should install the latest security updates provided by their Linux distribution.
Because many vendors backport patches without changing the kernel version significantly, verifying vendor security advisories is more reliable than relying solely on uname -r.
Disable Nested Virtualization
If immediate patching is not possible, disabling nested virtualization removes the vulnerable execution path.
For Intel:
kvm_intel.nested=0
For AMD:
kvm_amd.nested=0
This mitigation significantly reduces exposure in environments hosting untrusted virtual machines.
