This document describes the Januscape (CVE-2026-53359) vulnerability discovered and reported by Hyunwoo Kim (@v4bel). It is a KVM escape vulnerability that lets a guest escape to the host in a KVM/x86 environment. To the best of public knowledge, this is the first guest-to-host exploit research triggerable on both Intel and AMD rather than being limited to a single architecture.
Januscape is a use-after-free vulnerability in the shadow MMU emulation of KVM/x86. It can trigger the bug with guest-side actions alone to corrupt the host kernel's shadow page, and it can threaten the guest-host isolation of KVM/x86 hosts that accept untrusted guests and expose nested virtualization, particularly multi-tenant x86 public clouds (GCP, AWS, etc.).
In fact, Januscape was successfully used as a 0-day exploit in Google kvmCTF.
For the detailed technical information, see here.
Note
After reporting this vulnerability to [email protected], the agreed embargo has ended, so the exploit is posted to oss-security and this Januscape document is published. For the disclosure timeline, see the technical detail document.
Running the PoC inside a guest VM can trigger a host kernel panic. A full escape exploit that works in a controlled environment also exists, but it is not released at this time and is planned to be released in the very distant future.
On distributions like RHEL, /dev/kvm is world-writable (0666), so an unprivileged user could also turn this vulnerability into a reliable LPE to root. That said, doing so would be like paying gold for garbage, so I won't bother covering it.
- Inside the guest VM, install the headers and build the module.
# sudo apt-get install -y build-essential linux-headers-$(uname -r)
# make
- Load the module inside the guest. KVM holds the raw VMX/SVM state, so unload it first. Load with no argument on Intel, and with amd=1 on AMD.
[Intel]
# sudo rmmod kvm_intel; sudo insmod poc.ko
[AMD]
# sudo rmmod kvm_amd; sudo insmod poc.ko amd=1
- The race starts, and within seconds to minutes the host KVM panics.
[*] poc step 4/4: race live -- host DoS triggering
...
kernel BUG at arch/x86/kvm/mmu/mmu.c (pte_list_remove)
Comm: qemu-kvm
This PoC is intended to provide accurate information. Do not use it on systems you are not authorized to test.
Januscape (CVE-2026-53359) covers the range from 2032a93d66fa (2010-08-01) to 81ccda30b4e8 (2026-06-16).
In other words, this vulnerability lay dormant for about "16 years".
There are two impacts in total:
- KVM escape: With guest-side actions alone, an attacker can compromise the host that runs their VM. For example, an attacker who has rented just a single instance on a public cloud could panic the host kernel to take down every other tenant VM on the same physical machine (DoS), or run code with root privilege on the host to take over the host and all the guests on it (RCE).
- LPE: On distributions such as RHEL,
/dev/kvmis world-writable (0666), so an unprivileged user can also use this vulnerability as a reliable LPE to gain root.
If you operate an x86 KVM host that accepts multi-tenant guests and supports nested virtualization, or use an instance on top of one, check that the 81ccda30b4e8 patch is applied to the host kernel.
No. The vulnerability is triggered only on the Intel and AMD architectures. That said, if you have not yet patched the previously published ITScape (CVE-2026-46316), your arm64 hosts are also vulnerable, so apply the patch promptly.
No. Unlike the commonly published QEMU escape vulnerabilities, Januscape occurs in in-kernel KVM, so it is triggered independently of QEMU's emulation. Because of this, it can also threaten large public clouds that implement and use their own virtualization stack.
Yes. Inserting the module requires guest kernel privilege. When you are allocated an instance on a public cloud, you usually have root on your own VM, so this is satisfied. In a scenario without guest root, it must be chained with an LPE such as Dirty Frag.