Another serious flaw is making the rounds, this time the worst-case scenario for the cloud: escaping a virtual machine onto the host. Dubbed Januscape and tracked as CVE-2026-53359, it lives in the shadow MMU code of the KVM hypervisor. It is roughly 16 years old and, according to its authors, the first publicly known guest-to-host exploit that works on both Intel and AMD. It was discovered by Hyunwoo Kim (@v4bel).

For multi-tenant environments this is a “lights out” class of flaw: a single malicious tenant can break out of their VM and reach the host, and through it every other guest on the same physical machine.

Where the Bug Lives

For memory virtualization, KVM on x86 uses either hardware support (Intel EPT, AMD NPT) or the older shadow paging mechanism. The shadow MMU keeps its own bookkeeping pages that mirror the guest’s page tables. This code has been in the kernel largely unchanged since 2010 (kernel 2.6.36) and is shared between the Intel and AMD backends. That is why one bug hits both platforms at once.

What the Bug Is

It is a use-after-free caused by type confusion. When KVM looked for a bookkeeping page to reuse, it matched candidates by guest frame number (GFN) alone, without checking whether the page actually served the same role: the same page-table level and the same access mode. Two different pages can share the same address while doing entirely different jobs.

Under a specific sequence of guest operations using nested virtualization, a race occurs: the host associates a shadow page-table entry with the wrong GFN. Later, a stale reverse-mapping (rmap) entry is dereferenced during dirty logging or MMU-notifier invalidation, corrupting host kernel memory. Crucially, the attacker controls where the write lands, but not what gets written. That is enough to build full control from it.

Why Both Intel and AMD

The bug behaves the same on both architectures because the shadow MMU is shared. Only the final, hardest step, turning corruption into full control, differs, requiring different work on Intel versus AMD.

There is one condition: nested virtualization must be enabled on the host. Even if the host uses hardware EPT or NPT by default, enabling nested virtualization forces KVM back onto the legacy shadow MMU path, which is exactly where the bug sits.

What the Exploit Can Do

The attacker needs root inside the guest, which on a rented cloud instance is the norm. With that:

  • The public PoC reliably panics the host from a guest. That alone is an availability attack: you crash the host and take down every other VM on that machine.
  • The withheld, full version, according to the author, runs code as root on the host. That opens access to every other guest sharing the physical machine.

In other words, the isolation guarantee that all multi-tenant virtualization stands on collapses.

You Must Patch Two CVEs

This matters: fully closing the hole requires two coupled fixes, not one.

  • CVE-2026-53359 is Januscape proper (commit 81ccda30b4e8)
  • CVE-2026-46113 is a sibling use-after-free in the same page-reuse logic (commit 0cb2af2ea66a, May 2026)

Patching only one leaves the system exploitable.

How to Defend

Update the kernel. The fix landed in mainline on June 19th, and on July 4th, 2026 the patched stable releases shipped:

7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260

If you cannot update right away, cut off the attack path by disabling nested virtualization for untrusted guests:

# Intel
echo "options kvm_intel nested=0" > /etc/modprobe.d/kvm-nested.conf
# AMD
echo "options kvm_amd nested=0" > /etc/modprobe.d/kvm-nested.conf

After reloading the module (or a reboot), check:

cat /sys/module/kvm_intel/parameters/nested   # Y or N

If you do not expose nested virt to guests, it is good practice to keep it off anyway. It is a large attack surface for a feature most workloads do not need.

Timeline

  • May 28, 2026: fix for the sibling CVE-2026-46113 (commit 0cb2af2ea66a)
  • June 19: the Januscape fix merged into mainline (commit 81ccda30b4e8)
  • July 4: patched stable releases for all supported lines

Takeaway

Januscape is a reminder that the oldest code can be the most dangerous. The shadow MMU path sat untouched since 2010, yet it offered a route from a guest straight into the host kernel on both major architectures. If you run a host with untrusted guests, treat this as a fire: update the kernel to the July 4th release or later, and until you do, disable nested virtualization.

While you are at it, it is worth reading our write-up of another fresh kernel hole, DirtyClone, as yet another example of how local escalation breaks isolation assumptions.

Sources: Cloud Security Alliance Labs, The Hacker News, SecurityWeek