Januscape (CVE-2026-53359): 16-year-old KVM UAF escapes VMs on Intel and AMD

Researcher Hyunwoo Kim (@v4bel) disclosed Januscape — CVE-2026-53359 — on July 6, 2026, when the coordinated embargo lifted. It is a use-after-free in KVM's shadow MMU that, from a root shell inside a guest VM, takes the attacker to arbitrary host-kernel memory corruption on both Intel VMX and AMD SVM. Stable Linux kernels shipped the fix on July 4, 2026. Kim characterises the bug as the first guest-to-host escape triggerable on both Intel and AMD in public disclosure history.

A working proof-of-concept is published on GitHub; Kim states a separate, unreleased chain turns the same primitive into host code execution. The public PoC is enough to panic the host from an ordinary guest.

The bug

KVM's shadow MMU virtualises guest page tables when hardware nested paging is not in use or when the guest itself runs nested virtualization. Shadow pages have a role field that encodes what a page represents; two of those role bits — direct versus indirect — describe fundamentally different structures.

kvm_mmu_get_child_sp() reuses an existing shadow page when a lookup finds one whose guest-frame-number matches the request. Until the fix, the reuse condition compared only the gfn — not the full role.word. When a direct and an indirect shadow page shared a gfn, KVM would hand back the wrong one. Freed shadow pages could then remain referenced by stale parent pointers, and the attacker could reach through those dangling references. The fix, commit 81ccda30b4e8 authored by KVM maintainers Paolo Bonzini and Sean Christopherson, extends the reuse check to compare role.word as well, so the two roles are no longer conflated.

The bug has been present since the shadow MMU took its modern shape in 2010 — sixteen years of exposure across every distribution that ever built KVM in.

Affected versions and patch status

The vulnerable code path is in mainline until commit 81ccda30b4e8 was merged on June 19, 2026. Fixed stable releases went out on July 4:

• 7.1.3
• 6.18.38
• 6.12.95
• 6.6.144
• 6.1.177
• 5.15.211
• 5.10.260

Everything before those points on the corresponding stable branch is exposed, subject to the exploitation prerequisites below. Distribution kernels lag mainline by variable windows; check the uname -r of running hosts, not the package version, and cross-reference against your distro's advisory stream. Disclosure was coordinated with security@kernel.org on June 12, 2026; the CVE was assigned on July 4 and the embargo lifted July 6.

Exploitation status

There is no remote vector. The exploit needs two things from the guest side:

1. Root inside the VM. This is a common condition on rented cloud instances and on developer or CI VMs where the tenant already controls the guest.
2. Nested virtualization exposed by the host (kvm_intel.nested=1 or kvm_amd.nested=1). This is the default on most distributions.

Given those two conditions, the GitHub write-up walks the primitive through to a host panic in the public PoC; Kim states the private variant reaches host code execution. Januscape was Kim's zero-day submission to Google's kvmCTF, the controlled reward program that offers up to $250,000 for a full guest-to-host escape.

No named in-the-wild exploitation was reported at press time — the bug is one embargo-day old. Multi-tenant KVM operators should treat that as the calm before the exploit-kit adoption curve, not the all-clear.

Action checklist

1. Inventory KVM hosts by running kernel. Pull uname -r from every hypervisor and cross-reference against the fixed stable version for that branch. A patched-but-not-rebooted host is a vulnerable host.
2. Patch and reboot the multi-tenant population first. Public cloud edges, shared developer bastions, CI runners on KVM, and any hypervisor that hosts guests you don't own the entirety of the guest OS on.
3. If you can't patch immediately, disable nested virtualization for untrusted guests: boot with kvm_intel.nested=0 or kvm_amd.nested=0, then reload the kvm_intel / kvm_amd module. This removes the attack path but breaks any workload that itself runs a hypervisor inside.
4. Audit which guests hold root. On a shared host, "just a customer VM" is the exploit's starting point. Root-in-guest exposure is the actual threat model.
5. Watch for host-side crashes. The public PoC panics the host; a spike in unexplained hypervisor panics on unpatched fleets is a live tell.

Context

Januscape lands in a lineage of KVM escapes that have accelerated year-over-year. 2024 saw CVE-2024-26582 and the round of KVM/x86 hardening pushed by Google's kvmCTF launch; 2025 delivered several nested-VM state confusion bugs. What makes CVE-2026-53359 unusual is the cross-vendor reach: shadow MMU code is the piece KVM shares across Intel and AMD, so a bug there hits both without per-architecture engineering. Cloud operators who ship a mixed VMX/SVM fleet had, historically, been able to plan around vendor-specific escapes. That option is closed for this class.

The structural takeaway is that the shadow MMU — reintroduced by nested virtualization even where hardware nested paging is otherwise the norm — remains one of the most fertile guest-to-host surfaces in the kernel. Fleets that had already tightened nested=0 on untrusted-guest tiers absorbed today's news without emergency work. Everyone else is on the patch-and-reboot treadmill until the July 4 stable releases are running on every hypervisor.