Januscape: A 16-Year-Old Linux KVM Escape Bug

Status as of August 3, 2026: patched in stable kernels 6.1.177, 6.6.144, 6.12.95, 6.18.38, and 7.1.3, released July 4, 2026. Proxmox has since shipped kernel packages incorporating the fix. NVD had not assigned a CVSS score to this CVE as of several of the sources this post draws on, treat the absence of a score as a gap in the record, not a signal the bug is low-severity.

A bug that's been sitting in Linux's KVM hypervisor code since 2010, through sixteen years of review by some of the best kernel engineers alive, turned out to let a guest virtual machine crash its host, and possibly worse. CVE-2026-53359, nicknamed Januscape, is the first publicly known KVM guest-to-host exploit that works on both Intel and AMD hardware. If you run Proxmox, or anything else built on KVM, this is worth your attention even if you've never had a reason to think about hypervisor internals before.

What Januscape actually is

The bug lives in KVM's shadow MMU code, memory management logic that Intel's VMX/EPT and AMD's SVM/NPT virtualization extensions share. Security researcher Hyunwoo Kim (publishing as @v4bel) found and privately reported it, his third Linux kernel exploit disclosure in roughly two months, following an earlier bug called Dirty Frag in May 2026 that extended the same general bug class as Dirty Pipe and, notably, Copy Fail, the CVE-2026-31431 kernel privilege escalation we covered earlier this year.

The publicly released proof-of-concept demonstrates a guest VM crashing its host, a kernel panic triggered from inside a guest with no special privileges beyond what a normal VM tenant has. Kim states a separate, unreleased exploit goes further: full code execution on the host as root. If that holds, any other guest VM sharing that physical host is exposed to whatever a root-level compromise of the host can do, which is to say, everything.

Kim originally submitted this as a zero-day to Google's kvmCTF program, a controlled bug-bounty environment for KVM vulnerabilities that pays up to $250,000 for a full guest-to-host escape.

The two-patch trap

This is the detail worth reading twice. Januscape doesn't have one fix, it has two: the primary patch (commit 81ccda30b4e8, tracked as CVE-2026-53359) and a companion frame-number fix (commit 0cb2af2ea66a, tracked as a separate CVE, CVE-2026-46113). The July 4 stable kernel releases bundle both together, so if you're pulling a current stable kernel, you're covered. But if you're applying patches manually, backporting to an older kernel, or your vulnerability scanner only checks CVE IDs individually, you can end up patching CVE-2026-53359 and walking away believing you're covered while CVE-2026-46113 is still open, and still fully exploitable on its own.

# Verify both patches are present, don't check just one CVE ID
git log --oneline | grep -E "81ccda30b4e8|0cb2af2ea66a"

On distro kernels rather than a self-built one, check your distribution's own CVE tracker for both IDs explicitly, a fixed kernel package should reference both commits, not just one.

Whether this actually affects your Proxmox box

Proxmox VE runs on Linux KVM, so the underlying bug is present. Whether it's exploitable on a given Proxmox host depends on configuration, not just patch status, and this is where the Proxmox community forums did some useful digging in real time. Guest-to-host exploitation of Januscape requires nested virtualization to actually be exposed to the guest, which needs either the guest explicitly requesting it or the VM using the "host" CPU model. Nested virtualization is enabled at the kernel module level by default on most systems, but Proxmox VE does not default individual VMs to the "host" CPU type, so a stock Proxmox VM, with a non-host CPU model and nothing explicitly enabling nested virt, is not exposed to the guest-to-host path even on an unpatched kernel.

That's a meaningfully narrower blast radius than "every Proxmox install is instantly compromisable," and it's worth knowing precisely rather than either panicking or dismissing this. Check your actual exposure:

# Check whether nested virtualization is enabled on the host
for p in /sys/module/kvm_intel/parameters/nested /sys/module/kvm_amd/parameters/nested; do
  [ -e "$p" ] && printf "%s=%s\n" "$p" "$(tr -d '\n' < "$p")"
done

If any VM on the host uses the "host" CPU model, or you've explicitly enabled nested virtualization for a guest (common if you're running a VM inside a VM, or testing a hypervisor inside Proxmox itself), that guest has the standing to attempt the exploit. If none do, your exposure on an unpatched kernel is the host-crash path at most, not confirmed guest-to-host code execution, still worth patching, meaningfully less urgent as an emergency.

What to actually do

1. Patch your kernel. Verify both commits are present, not just one CVE ID, using the check above.
2. If you can't patch immediately on a multi-tenant host, disable nested virtualization where it isn't actually needed: options kvm-intel nested=N (or the AMD equivalent) and reload the module, or set it at boot via your distro's module config.
3. Restrict /dev/kvm permissions if unprivileged users on the host have access to it, some distributions ship this world-writable by default, which independently allows local privilege escalation to root even without the guest-to-host path.
4. On genuinely multi-tenant infrastructure that can't be patched right away, live-migrate untrusted tenant VMs off the unpatched host before you patch or reboot it, not after. A public proof-of-concept exists; treat opportunistic scanning as a real possibility, not a hypothetical.
5. Audit host kernel logs for the past 30 days for oops or panic events referencing arch/x86/kvm/mmu/mmu.c. That's retroactive detection, not prevention, but it's the only visibility you have into whether someone reached this primitive before you patched.
   If you have specific reason to suspect a full guest-to-host compromise already happened on a given host, not just a crash, treat that host as compromised: rotate any secrets accessible from it, review cluster credentials and storage access, and consider rebuilding the node from known-good media rather than trusting an in-place cleanup.

Why hypervisor bugs like this matter even for a single-box homelab

It's easy to read "cross-tenant risk on shared cloud infrastructure" and conclude a single-server homelab running a handful of your own VMs isn't the audience for this. That's mostly true for the headline risk, nobody else's VM is sharing your Proxmox box. But the underlying lesson holds regardless of scale: VM isolation is a property the hypervisor has to actively maintain, not a guarantee that comes free with virtualization. A 16-year-old bug in code reviewed by some of the best kernel engineers in the world is a reminder that "it's a VM, so it's isolated" is an assumption worth periodically checking, especially if you're running anything you don't fully trust, a friend's game server, a client's app, a security research VM, inside the same hypervisor as things you do trust.