TL;DR
- what: A use-after-free in Linux KVM's shadow-page code (CVE-2026-53359, 'Januscape') lets a guest VM corrupt host kernel state.
- impact: A single rented instance can panic the host and drop every co-tenant VM; a withheld exploit escalates the same bug to root code execution on the host.
- fix: Patched in stable kernels 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211 and 5.10.260 (commit 81ccda30b4e8) on July 4, 2026; if you can't patch, set kvm_intel.nested=0 or kvm_amd.nested=0.
- who: Any x86 KVM host running untrusted, multi-tenant guests with nested virtualization enabled — cloud and hosting providers first.
A guest virtual machine on Linux KVM can corrupt the host kernel that runs it. The bug, named Januscape and tracked as CVE-2026-53359, is a use-after-free in KVM's shadow MMU — the page-table code KVM shares across Intel and AMD. The public proof-of-concept reliably panics the host from inside a guest. The researcher who found it, Hyunwoo Kim (@v4bel), says a separate, unreleased exploit turns the same flaw into full code execution on the host as root.
Two facts make this one worth moving on now. It is the first guest-to-host escape known to trigger on both Intel and AMD x86, and the vulnerable code has been sitting in the kernel since August 2010 (commit 2032a93d66fa, the 2.6.36 era). It went unnoticed for roughly 16 years. Kim submitted it as a zero-day to Google's kvmCTF, the controlled reward program that pays up to $250,000 for a full guest-to-host escape.
What actually breaks
To run a VM, KVM maintains its own private page tables that mirror the guest's memory layout. When it needs one of these tracking pages, it looks for an existing one to reuse — and it matched candidates by memory address alone, ignoring the page's type, or 'role.' Two different kinds of tracking page can live at the same address while doing completely different jobs, so KVM would sometimes grab the wrong one. That scrambles its internal records of which page maps where.
Most of the time the kernel notices the inconsistency and shuts itself down on the spot to avoid doing damage. That deliberate crash is what the public PoC triggers: one guest knocks over the entire host and takes every other VM on the machine down with it. The rarer, worse path is when the freed tracking page is handed out for another use before cleanup runs; the cleanup then writes a value into memory KVM no longer owns. The attacker controls where that write lands, not what gets written — but that limited primitive is enough to build toward host code execution.
Who is exposed
The attack needs two things from the guest side, and both are common in the cloud: root inside the VM, which you get by default on a rented instance, and nested virtualization exposed by the host. Even hosts using hardware EPT or NPT by default get dragged back through the legacy shadow MMU the moment nested virtualization is in play — and that is exactly where the bug lives. The exploit needs no cooperation from QEMU or any userspace VMM. It is purely an in-kernel KVM bug.
⚠️ The multi-tenant blast radius — An attacker who rents one instance on a vulnerable host can panic the physical machine, dropping every co-tenant VM. Kim's withheld full exploit runs code as root on the host, which would expose every other guest on that box to host-level access. On distributions where /dev/kvm is world-writable (0666), such as RHEL, the same bug also works as a local privilege escalation to root — though guest-to-host is the higher-impact use.
The fix
The patch is a one-line change to kvm_mmu_get_child_sp(): the reuse condition now checks role.word alongside the gfn, so a shadow page is reused only when both the frame number and the role match. KVM maintainer Paolo Bonzini wrote it; it merged to mainline on June 19, 2026 (commit 81ccda30b4e8). Fixed stable kernels shipped July 4, 2026.
- Patched stable versions: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, and 5.10.260.
- Confirm your kernel carries commit 81ccda30b4e8 — distribution backports may use a different version string, so check the package changelog, not just uname -r.
- No mitigation available? Disable nested virtualization for untrusted guests: kvm_intel.nested=0 or kvm_amd.nested=0. That removes the attack path.
- ARM64 hosts are not affected by Januscape (that is a separate issue, ITScape / CVE-2026-46316).
Don't wait for a CVSS score
NVD had not assigned a CVSS score at disclosure. Do not treat that absence as a reason to delay. The public PoC demonstrates a reliable host panic from a guest using a loadable kernel module and seconds to minutes of racing — a working denial-of-service against an entire physical host is already in the wild, and the code-execution variant is being held back, not proven impossible.
A pattern, not a one-off
Januscape is Kim's third Linux kernel disclosure in about two months. In May 2026 he published Dirty Frag (CVE-2026-43284 / CVE-2026-43500), a page-cache write chain delivering deterministic root on most major distributions and extending the Dirty Pipe / Copy Fail bug class. In June came ITScape (CVE-2026-46316), the first publicly demonstrated guest-to-host escape on KVM/arm64. Januscape adds the x86 side. Separately, another KVM x86 shadow-paging use-after-free (CVE-2026-46113) was fixed in May 2026 — making two shadow MMU use-after-frees in the same legacy code path inside two months. If you host untrusted x86 guests with nested virtualization, treat those hosts as high-priority patch targets today.
Originally published on RedEye Threat Intelligence.
Top comments (0)