16-Year-Old Linux Bug Lets Attackers Escape Virtual Machines on Intel and AMD

Key points

• Security researcher Hyunwoo Kim disclosed Januscape (CVE-2026-53359), a Linux kernel flaw patched in June 2026 that had lived in the code for roughly 16 years.
• The bug lets an attacker with root access inside a virtual machine break out and run code on the physical host, or crash it and knock every other tenant offline.
• Kim says it is the first guest-to-host escape that works on both Intel and AMD chips.
• On Red Hat Enterprise Linux and similar distributions where /dev/kvm is world-writable, an ordinary user account can also use the bug to become root.
• Administrators should confirm patch commit 81ccda30b4e8 is applied to any KVM host running multi-tenant workloads.

A Linux kernel flaw that hid in plain sight for about 16 years lets an attacker escape a virtual machine and take over the physical computer running it.

The bug, nicknamed Januscape and tracked as CVE-2026-53359, was found by security researcher Hyunwoo Kim. It was patched in June 2026, but not before being used as a zero-day (a flaw the software maker did not know about) in Google's kvmCTF bug bounty program.

The technical root cause is a use-after-free (a memory-handling mistake where code keeps using data that has already been thrown away) inside the shadow MMU emulation of KVM/x86, the virtualization engine built into the Linux kernel for Intel and AMD processors. In plain terms: the kernel gets confused about what is still in memory, and an attacker can abuse that confusion.

What can an attacker actually do with this?

They can break out of a rented virtual machine and seize the whole server it sits on. A virtual machine is a software computer running inside a real one. On public clouds like Google Cloud or Amazon Web Services, one physical server hosts dozens of these virtual machines, each rented by a different customer.

Kim's writeup, first reported by BleepingComputer, spells out the two outcomes. An attacker who rents a single cloud instance can crash the host kernel and take every other tenant's virtual machine offline with it. Or they can run code with root privileges (full administrator rights) on the host and quietly take over every guest running there.

"With guest-side actions alone, an attacker can compromise the host that runs their VM," Kim wrote on Monday.

He also notes something unusual. Most guest-to-host escapes work on one chip family. Januscape works on both Intel and AMD.

Who is exposed?

Any KVM/x86 host that accepts workloads from more than one customer. That is the default arrangement on major public clouds. It is also the arrangement inside plenty of private hosting shops and internal virtualization clusters.

There is a second exposure worth flagging. On some Linux distributions, notably Red Hat Enterprise Linux, the /dev/kvm device is writable by any local user. On an unpatched machine, that means a regular login account can trigger CVE-2026-53359 to gain root, no virtual machine escape required.

What should administrators do?

Apply the fix. Kim points specifically at patch commit 81ccda30b4e8 in the upstream Linux kernel, and administrators should confirm it has landed in whatever distribution kernel they run.

Kim has published a technical writeup and a proof-of-concept that triggers a host kernel panic (a crash). A full working exploit for remote code execution on the host is not being released, he says, and will not be for the foreseeable future. That is a small mercy, not a reason to delay patching.

Does this chain with anything else?

Yes, and this is the part that should worry defenders. In May 2026, Kim disclosed a separate Linux local privilege escalation called Dirty Frag, which chains two page-cache write bugs: CVE-2026-43284 in xfrm-ESP and CVE-2026-43500 in RxRPC. It gives root on Ubuntu, RHEL, CentOS Stream and Fedora.

An attacker who lands on a guest as an unprivileged user could use Dirty Frag to become root inside the guest, then use Januscape to break out to the host. Two bugs, full takeover. Patch both.

For ordinary cloud customers there is nothing to do directly. Your provider owns the host kernel. Ask them, in writing, whether commit 81ccda30b4e8 is applied across their fleet.