Januscape KVM Bug Is Actually Two Flaws: One Patch Won’t Cover You

For sixteen years, a single line of missing logic sat inside the Linux kernel’s virtualization code, waiting. This week, someone finally found it — and what they found breaks the one promise a hypervisor is supposed to keep: that a virtual machine can never touch the physical computer running underneath it.

The bug is nicknamed “Januscape,” and it isn’t one vulnerability — it’s two, shipped together, and both have to be patched or the fix does nothing.

Security researcher Hyunwoo Kim disclosed the primary flaw, CVE-2026-53359, along with a working proof-of-concept that crashes a host machine from inside a guest VM. Kim says a more capable exploit, one that hands an attacker full control of the host rather than just crashing it, exists but hasn’t been made public.

The catch most early coverage has missed: the actual upstream fix is two coupled kernel commits, addressing CVE-2026-53359 and a companion bug, CVE-2026-46113, together — commit 81ccda30b4e8 for the first, 0cb2af2ea66a for the second. A system that only patches the first CVE is still exploitable. If you’re checking patch status by CVE ID alone — which is how most admins check — you can come away thinking you’re covered when you’re not.

Twofer one fix

The bug has so far received attention and remediation suggestions as a one-and-done patch fix. But, the actual fix ships as two coupled kernel commits, not one. The upstream fix actually comes as two separate kernel patches, not one. The first patch, commit 81ccda30b4e8, fixes the main bug, CVE-2026-53359. The second, commit 0cb2af2ea66a, fixes a related bug, CVE-2026-46113, in the same part of the code. You need both.

A system with only the first patch installed is still vulnerable. If you’re checking patch status by CVE ID alone — which is how most admins check — you can come away thinking you’re covered when you’re not.

Here’s why it matters. A Kernel-based Virtual Machine (KVM) runs underneath most of the cloud — major providers, VPS hosts, CI/CD pipelines, platforms like Proxmox. A single physical server usually hosts dozens of separate customers’ VMs at once, each assuming the others can’t reach it. Januscape breaks that assumption.

At minimum, one exploited VM crashes every tenant on that host, not just the attacker’s own. At worst, the attacker’s code runs on the host itself, putting every other customer’s VM within reach. Google’s own bug bounty pays up to $250,000 for exactly this outcome — a sign of how seriously the industry rates it.

Technically, CVE-2026-53359 is a use-after-free bug: KVM keeps internal bookkeeping pages to track a guest’s memory, and under the right conditions, it reuses one of those pages for the wrong purpose without checking that the reuse is valid. That small oversight is enough for a malicious guest to corrupt memory on the host itself.

Depending on how it’s exploited, the result ranges from crashing the entire physical machine — taking down every other VM running on it — to potentially giving the attacker full control of the host. For anyone running multi-tenant infrastructure, like a cloud provider hosting many customers’ VMs on the same hardware, that second outcome means one malicious customer could reach into everyone else’s data. That’s why this is drawing attention well beyond the usual Linux-kernel-bug audience: it’s not a bug in an application, it’s a bug in the wall between tenants.

How it works

The bug is in a KVM function that decides whether to reuse an internal memory-tracking page. It makes that call based on one identifier alone, without double-checking the page’s actual role — so a guest can trick the host into reusing that page for the wrong purpose, corrupting host memory.

Here’s what that looks like in practice: say a VM is set up to track its own memory pages under internal IDs, and the host reuses page #12 for a new purpose once the VM says it’s done with it. Normally that’s safe. But if a guest can make the host reuse page #12 while it’s still holding something sensitive — before the host has actually finished with it — the guest ends up corrupting memory it was never supposed to touch. That mismatch is enough to crash the host; Kim says, steered more precisely, it can be pushed to full code execution instead.

It hits both Intel and AMD systems, since the flaw is in shared x86 code, not anything vendor-specific. KVM/arm64 is unaffected — that’s a separate bug, ITScape (CVE-2026-46316), disclosed in June.

Two caveats worth knowing: exploitation requires nested virtualization to be enabled, which isn’t universal — Proxmox says disabling it is the only mitigation until a fixed kernel ships. And on distributions where /dev/kvm is world-writable by default (RHEL, EL8+), any local user can trigger this directly, no VM or cloud tenant involved — a wider exposure than the “malicious cloud tenant” framing most coverage has used.

Where it came from

The vulnerable code dates back to a kernel commit from 2010, meaning the bug sat unnoticed in shipping kernels for roughly 16 years before Kim found it. It was fixed upstream in June 2026, and that fix reached most major stable kernel versions by July 4.

Kim found Januscape through kvmCTF, a bug bounty program Google launched in 2024 specifically to catch flaws in KVM before they turn up in Android or Google Cloud’s own infrastructure. The program pays up to $250,000 for a full guest-to-host escape like this one, and under its rules, Google only gets the technical details after a fix has already shipped — which is why the public writeup landed so close to the patch date.

This is Kim’s third major Linux kernel disclosure in about two months. In May, he published Dirty Frag, a page-cache exploit in the same bug family as Dirty Pipe, delivering root access on most major distributions. In June came ITScape, the first publicly documented KVM/arm64 guest-to-host escape. Januscape is the first of Kim’s three to work on both Intel and AMD systems.

Scoring is split

NVD hasn’t assigned a CVSS score to CVE-2026-53359 yet. Red Hat has scored it independently, though: 7.0 out of 10, rated “Important.”