Januscape (CVE-2026-53359): 16-year KVM guest-to-host escape

The bug lives in KVM’s shadow-page management code — the part of the hypervisor that fakes a guest’s memory-management unit when hardware assists like Intel EPT or AMD NPT aren’t doing the work. In kvm_mmu_get_child_sp(), the routine that decides whether an existing shadow page can be reused for a new mapping, the reuse test only matched on the guest frame number. It did not check the page’s role — the bitfield that records how that shadow was originally built. A guest could arrange for a page constructed under one role to be handed back for a mapping that expected a different one, and the resulting mismatch is a use-after-free in the host kernel. The upstream patch, commit 81ccda30b4e8, is one line: the reuse condition now checks role.word alongside gfn. That is the whole fix.

The flaw sits in code introduced by commit 2032a93d66fa in August 2010 for kernel 2.6.36. It has been in every mainline kernel since. Researcher Hyunwoo Kim (@v4bel) submitted it through Google’s kvmCTF program earlier this year and named it Januscape. Public disclosure was July 6, 2026, via The Hacker News, with follow-on coverage in BleepingComputer. SUSE has rated it CVSS v3.1 8.8 and v4.0 9.3; NVD has not published its own score yet. It is not on CISA KEV.

What the PoC actually does

The public proof of concept reliably panics the host kernel from an unprivileged guest — enough to demonstrate the use-after-free, not enough to weaponize. Kim says a separate exploit chain that turns the same primitive into root code execution on the host exists but has been withheld. That is the responsible-disclosure norm for kvmCTF submissions and is the reason vendors got a chance to ship stable-kernel updates before the details went public. Treat the RCE claim as sourced but unverified from outside; treat the guest-to-host panic as demonstrated.

Where the fix landed

The one-liner was merged upstream on June 19, 2026, and backported into the stable branches on the same day. As of publication, the fixed kernels are:

• Mainline / 7.1.x — 7.1.3
• 6.18.x — 6.18.38
• 6.12.x LTS — 6.12.95
• 6.6.x LTS — 6.6.144
• 6.1.x LTS — 6.1.177
• 5.15.x LTS — 5.15.211
• 5.10.x LTS — 5.10.260

Distribution kernels lag mainline. If you run RHEL, Ubuntu, Debian, SUSE, or Amazon Linux, watch the vendor security tracker — SUSE has already published its advisory; the other majors will follow. The Android common kernels (5.10 and 6.6 downstream) inherit the fix from the LTS backports the AOSP kernel team pulls, but the arrival window into your device’s OTA is the usual months, not weeks.

Who is actually reachable

The bug requires the attacker to be running code inside a KVM guest. That sounds narrow and mostly is — but the population where that condition is met on demand is larger than the phrase “VM escape” implies:

1. Multi-tenant KVM hosts — the classic exposure. Public cloud providers who use KVM under the hood have their own hardening (jailed vCPU threads, tight seccomp on QEMU, separate hosts per tenant, live migration off unpatched hosts). Ask your provider what they’ve patched, not whether they have. This is not a bug you want sitting on a host you share.

2. Self-hosted KVM/libvirt with untrusted workloads — CI runners that execute pull-request code, sandboxes for user-supplied builds, VDI hosts running staff Windows images with browser access, malware analysis rigs. If the guest kernel or guest userland is anywhere on the internet’s reach, the guest can plausibly reach the vulnerable path.

3. Systems where /dev/kvm is world-readable — some RHEL variants ship with /dev/kvm mode 0666, which lets any local unprivileged process act as a guest through KVM ioctls without needing an actual VM. Red Hat has flagged this configuration specifically as raising the effective attack surface from “hostile guest” to “any local unprivileged user.” If you have shared shells or web apps running on a KVM-capable host, this is the case that turns the bug into a local privilege escalation.

Single-tenant hypervisors running only your own trusted workloads sit at the bottom of the priority list. Still patch. Not this week’s fire.

What to actually do

• If you run a shared KVM host of any kind, patch the host kernel to the stable release above for your series, or drain it and rebuild. Reboot is required — this is a kernel fix, not a module.
• If /dev/kvm is world-accessible on any host with untrusted local users, restrict it now. chmod 0660 /dev/kvm and put the kvm group only on accounts that legitimately run VMs is the standard hardening; it does not fix the bug but it removes the “any local user” pathway until the kernel patch lands.
• For guests, there is nothing to do. The vulnerability is in the host code that services the guest — patching a guest kernel does not close it. Guest hardening is not a mitigation here.
• For managed KVM services (cloud, hosted VDI), ask the provider for their patch status against CVE-2026-53359 specifically. Not “yes we patch.” Not “our infrastructure is up to date.” The CVE ID.

The pattern

The interesting piece isn’t the RCE — that’s the headline. The interesting piece is that the vulnerable line has been in the tree since 2010. The shadow MMU is a legacy code path in the sense that most modern hosts run guests with hardware-assisted second-level translation (EPT on Intel, NPT on AMD) and never touch it. It is still there because there are still guests and hosts that use it, and because the code compiles into every kernel whether the runtime path is taken or not. A bug in code that nobody looks at, running under a subsystem that most operators think of as “hardware does that now” — that is a classic profile for something to sit for sixteen years and get found by a program specifically paid to look. See also the 16-year FatFs population runZero disclosed last week and the recent epoll use-after-free out of Google’s sister program, kernelCTF. The bounties are working. The code they are finding bugs in is not new code.

Patch the host, reboot it, and confirm the running uname -r matches the fixed release — not the installed package version, the running kernel. The difference is the one that matters.

Sourcing

• Researcher writeup and PoC: V4bel/Januscape (GitHub)
• Upstream patch series: lore.kernel.org
• The Hacker News: 16-Year-Old Linux KVM Flaw Lets Guest VMs Escape to Host
• BleepingComputer: New Januscape Linux flaw allows VM escape on Intel, AMD devices
• SUSE advisory: CVE-2026-53359
• Google kvmCTF program: security-research/kvmctf
• NVD entry: CVE-2026-53359