Januscape: 16-Year-Old KVM Bug Enables Guest-to-Host Escape on…

CVE-2026-53359 strikes the shared shadow MMU code in Linux KVM used by both Intel and AMD. The flaw has existed since 2010 and requires nested virtualization. The public PoC triggers a host kernel panic, while a non-public exploit reportedly achieves full arbitrary code execution.

On July 6, 2026, researcher Hyunwoo Kim disclosed CVE-2026-53359, dubbed "Januscape": a use-after-free in the Linux KVM shadow MMU code that allows a malicious virtual machine to compromise the physical host on both Intel and AMD processors. The bug has been present since 2010, the official PoC triggers a host panic, and a non-public version of the exploit reportedly enables full arbitrary code execution.

Key Takeaways

The bug resides in the shadow MMU code shared between Intel and AMD, the first publicly known cross-vendor KVM x86 guest-to-host escape.
The attack requires root in the guest VM and nested virtualization enabled, which forces the use of legacy shadow paging even on modern hardware.
The vulnerable code has been in-tree since commit 2032a93d66fa from August 2010: roughly 16 years in the kernel.
The fix is a single line in kvm_mmu_get_child_sp(), added by KVM maintainer Paolo Bonzini and available in kernel versions released July 4, 2026.

Why Nested Virtualization Exposes Legacy Code Never Designed for Multi-Tenant

KVM, the Linux kernel virtualization module, normally uses hardware extensions such as Intel EPT or AMD NPT to manage guest VM memory. These modern technologies do not traverse the vulnerable path. But when nested virtualization is active — a guest VM that itself runs a hypervisor — KVM must fall back to the old shadow paging, a software mechanism that translates guest addresses to host addresses via dynamically allocated data structures.

That is where the problem lies. In the shadow MMU code, the function kvm_mmu_get_child_sp() reuses shadow pages by comparing only the guest frame number (gfn), the page address. It does not verify the role.word, a field that describes the page type: two different types of tracking page can occupy the same physical address but serve distinct functions. The erroneous reuse corrupts KVM's internal structures, generating a use-after-free condition when a page is freed and reassigned before the kernel completes cleanup.

The mechanism is purely in-kernel: it requires no cooperation from QEMU, libvirt, or any other userspace component. This makes it particularly insidious, because the entire attack surface is contained within the Linux kernel and does not require complex virtualization stack configurations.

"the first guest-to-host exploit triggerable on both Intel and AMD, to the best of public knowledge" — Hyunwoo Kim (@v4bel)

Sixteen Years Hidden in a Single Line of Code

According to the cited source, the commit that introduced the vulnerable code is 2032a93d66fa, dated August 2010, in the era of kernel 2.6.36. The fix, commit 81ccda30b4e8, was merged into mainline on June 19, 2026. Between them: roughly 16 years, dozens of kernel releases, and the evolution of KVM from an experimental project to a pillar of global cloud infrastructure.

The patch is a single line: the addition of the role.word check to the reuse comparison in kvm_mmu_get_child_sp(). KVM maintainer Paolo Bonzini signed the commit. The kernel versions that include the correction were released on July 4, 2026: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260.

NVD has not yet assigned a CVSS score to the vulnerability. The dossier does not specify when such assignment will occur.

Host Panic Now, Code Execution with Non-Public Exploit

The PoC released publicly by Kim causes a host kernel panic, a total denial of service that halts all VMs running on the physical machine. Kim states he has separately developed a non-public exploit that turns the same bug into full arbitrary code execution on the host, gaining control of the physical machine from a guest VM.

The impact differentiates between the two vendors only in the final step: the path to shadow MMU corruption is identical on Intel and AMD, but the final pivot for full control requires architecture-specific work. This is Kim's third disclosure in roughly two months, following Dirty Frag in May 2026.

The researcher received a reward through Google's kvmCTF program, which offers up to $250,000 for complete guest-to-host escapes. The source does not specify the exact amount awarded for Januscape.

An Additional Vector on Systems with /dev/kvm World-Writable

The source cites a specific attack-surface expansion case for distributions such as RHEL where the device /dev/kvm is configured with world-writable permissions (0666). In this configuration, the same bug could be used as a local privilege escalation: an unprivileged user on the host system could theoretically reach root by exploiting the vulnerable path in the kernel. The source does not quantify the actual prevalence of this configuration or provide additional technical details on this vector.

It is not confirmed whether the full code-execution exploit exists beyond the researcher's claim. It is not verified whether the vulnerability has been exploited in-the-wild outside the controlled kvmCTF environment.

Why It Matters

The dossier does not specify specific remedial measures for operators beyond the availability of the listed kernel patches. The source does not quantify the number of systems with nested virtualization enabled for untrusted guests. It is unclear whether other independent researchers have reproduced the non-public full exploit.

ARM64 is explicitly excluded from this vulnerability: Januscape affects only the x86 architecture. The separate KVM/arm64 bug dubbed ITScape (CVE-2026-46316) is a distinct issue with its own identifier and mechanism.

Frequently Asked Questions

Is my cloud VM at risk?

The attack path requires the VM to have root and the host to have nested virtualization enabled. Most public cloud providers do not expose nested virtualization to generic tenants, but providers offering "bare metal" or dedicated instances with this feature enabled should verify their exposure.

Why did the bug last 16 years without being found?

The shadow MMU code is considered stable legacy: it is traversed only under specific conditions (nested virtualization), while the common path on modern hardware uses EPT/NPT. This bifurcation masked the vulnerability from regular audits until nested virtualization became standard infrastructure.

Is it verified that the full exploit actually works?

The public PoC that causes panic is verifiable. The exploit for full code execution is claimed by the researcher but not public and not independently confirmed in the dossier.

Sources

Information is based on the cited source and current as of publication.

Sources

Sources and references