If your organization runs virtual machines, whether that's your own on-premises virtualization stack or workloads rented from a public cloud provider, the promise underneath all of it is isolation: whatever happens inside a VM stays inside that VM. A vulnerability disclosed this week breaks that promise for a wide swath of Linux-based virtualization infrastructure, including the hypervisor technology that underpins major public clouds.
The vulnerability is called Januscape, tracked as CVE-2026-53359. It lives in KVM, the virtualization technology built into the Linux kernel that powers much of the world's cloud computing, and it allows a virtual machine to reach out and corrupt the memory of the physical host it is running on. In the worst case, that means a guest VM, the kind anyone can rent for a few dollars an hour, could be used to take over the server hosting it and every other customer's VM on that same machine. The flaw has been sitting in the Linux kernel, undetected, for roughly sixteen years.
You do not need to understand shadow page tables or memory management internals to understand why this matters: it means the wall between "my virtual machine" and "everyone else's virtual machine on the same physical server" has a crack in it, and that crack has existed since 2010.
Who found it, and how
Januscape was discovered and reported by security researcher Hyunwoo Kim, known online as @v4bel, a name that will be familiar to readers of our earlier coverage this year. Kim disclosed Dirty Frag (CVE-2026-43284 and CVE-2026-43500) in May and ITScape (CVE-2026-46316), the first publicly demonstrated guest-to-host escape on KVM's ARM64 implementation, in June. Januscape is his third major Linux kernel disclosure in roughly two months, and it extends the same line of research to the x86 side of KVM, the side that runs the overwhelming majority of public cloud instances.
Kim reported the flaw through the standard coordinated channel for Linux kernel security issues, the linux-distros mailing list, and the agreed embargo period has now ended, which is why the technical write-up, the proof-of-concept, and this article are all appearing now. A fix was merged into the mainline kernel in mid-to-late June 2026, and patched stable kernel releases shipped on July 4, 2026.
Notably, Kim says he had already used Januscape as a zero-day submission to Google's kvmCTF program, the controlled bug bounty competition that pays up to $250,000 for a full guest-to-host VM escape. That detail matters for two reasons: it confirms the exploit works well enough to be demonstrated under real competition conditions, and it means the flaw was known to at least one well-resourced party before this week's public disclosure, through a program specifically designed to responsibly capture exactly this kind of finding.
What is Januscape?
Januscape is a use-after-free vulnerability in KVM's shadow MMU, the code path the kernel uses to manage virtual machine memory when hardware-assisted paging is not being used directly. In plain terms: normally, modern CPUs handle the translation between a guest VM's memory addresses and the host's real memory addresses in hardware, using features called Intel EPT or AMD NPT. But when a virtual machine itself hosts another virtual machine inside it, a setup called nested virtualization, the outer host has to fall back to doing that translation in software. That software fallback is the shadow MMU, and it is where this bug lives.
The root cause
KVM keeps its own internal bookkeeping pages, called shadow pages, that track how a guest's memory is laid out. When KVM needs one of these tracking pages, it looks for an existing one it can reuse rather than allocating a new one.
The problem is how it decides what counts as a match. KVM was matching candidate pages purely by memory address (the guest frame number), without also checking what type, or "role," of page it was. Two shadow pages can share the same address while representing completely different things: one might be a direct mapping, the other a page-table shadow. KVM's reuse logic did not distinguish between them, so it would sometimes hand back the wrong kind of page.
That mismatch corrupts KVM's internal map of which memory belongs to which shadow page. The immediate consequence is usually a crash: the kernel notices its own bookkeeping is inconsistent and deliberately halts to avoid causing further damage, which is what the public proof-of-concept triggers.
The more serious consequence happens when timing lines up differently. If the freed tracking page gets reassigned to something else before cleanup finishes, that cleanup step writes a value into memory it no longer owns, a classic use-after-free. The attacker does not get to choose what gets written, only where, but a reliable write primitive into host kernel memory is a well-understood starting point for building toward code execution.
Kim has described Januscape as the first publicly known guest-to-host KVM exploit that works on both Intel and AMD systems rather than being tied to one vendor's chips. The underlying bug is identical on both platforms; only the final steps of turning it into full code execution differ by architecture.
What can an attacker actually do with it?
There are two distinct impacts, and it is worth separating them clearly for leadership conversations.
Denial of service, publicly demonstrated. The proof-of-concept Kim released reliably crashes the host kernel from inside a guest VM, using nothing more than a loadable kernel module and root access inside that guest, which is the default condition for anyone who rents a standard VM instance on a public cloud. Kim's demo shows the host kernel panicking within seconds to minutes of the module loading. Because the host is shared infrastructure, that single guest VM's crash takes down every other tenant's VM running on the same physical machine.
Remote code execution, confirmed but withheld. Kim states that a separate, working exploit exists that turns the same underlying bug into full code execution on the host, running as root. That exploit has not been released and, per Kim, will not be for the foreseeable future. If realized, this would let an attacker who merely rented one VM on a shared host take over that host entirely, along with every other guest running on it.
A privilege escalation path on some distributions. On distributions where the /dev/kvm device file is world-writable by default, which includes Red Hat Enterprise Linux, Kim notes that an unprivileged local user, no special guest VM required, could use this same bug as a reliable path to root on the local machine.
A chaining path for attackers without guest root. Triggering the primary exploit requires root privilege inside the guest VM. If an attacker does not already have that, Kim notes the flaw can be chained with a separate local privilege escalation bug, such as Dirty Frag, to get there first.
Unlike the QEMU-based VM escapes that get reported periodically, Januscape lives entirely inside the Linux kernel's own KVM code. It does not depend on QEMU's device emulation layer at all, which means it also threatens large cloud providers that have built their own custom virtualization stacks on top of KVM rather than using QEMU directly.
Who is affected?
The vulnerable code was introduced in a kernel commit from August 2010, corresponding to the 2.6.36 era, and remained present through every release until it was fixed this year. Kernel maintainer Paolo Bonzini authored the eventual patch, which changes the shadow page reuse logic to check both the memory address and the page's role before deciding a page can be reused.
Patched stable kernel versions shipped on July 4, 2026:
| Branch | Fixed version |
|---|---|
| 7.1 | 7.1.3 |
| 6.18 | 6.18.38 |
| 6.12 | 6.12.95 |
| 6.6 | 6.6.144 |
| 6.1 | 6.1.177 |
| 5.15 | 5.15.211 |
| 5.10 | 5.10.260 |
NVD has published the CVE record but, as of this writing, has not yet assigned a CVSS score in any version. Do not treat the absence of a score as an indicator of low severity; a guest-to-host escape affecting shared cloud infrastructure warrants urgent attention regardless of where a formal score eventually lands.
The conditions that matter
Two things need to be true for a host to be exploitable:
- The guest has root access, which is the default state for essentially any standard rented VM instance.
- Nested virtualization is enabled on the host, forcing KVM onto the vulnerable shadow MMU code path even on hardware that would otherwise use EPT or NPT directly.
The exploit requires no cooperation from QEMU or any other userspace virtual machine manager; it is purely a kernel-level bug reachable from inside the guest.
ARM64 hosts are not affected by Januscape specifically. The bug is confined to the x86 shadow MMU code shared by Intel and AMD. However, if you operate KVM on ARM64 and have not yet patched ITScape (CVE-2026-46316), that is a separate, already-disclosed guest-to-host escape on that architecture, and it should be addressed on its own timeline.
Where the risk concentrates
Multi-tenant public cloud environments are the primary concern. Any provider or customer running x86 KVM hosts that accept guests from parties they do not fully trust, and that expose nested virtualization to those guests, whether directly or through a self-service option, is exposed.
Nested virtualization offerings specifically. Cloud providers and enterprises that let customers run a hypervisor inside their VM (common for CI/CD pipelines that build and test VM images, or for customers running their own virtualization layer) are the deployments where this bug actually becomes reachable, since it is the fallback to shadow paging that creates the vulnerable path.
RHEL and similar distributions with a world-writable /dev/kvm. These deployments face the added risk of local privilege escalation independent of any guest VM at all.
How this relates to Kim's other 2026 disclosures
It is worth placing Januscape in context, since this is the third significant kernel finding from the same researcher in two months, and a related bug touched the same code area even more recently than that.
Dirty Frag (May 2026) chains two separate kernel bugs to deliver deterministic root privilege escalation on most major Linux distributions. Kim notes that Dirty Frag and Januscape can be chained together: an attacker without guest root can use Dirty Frag to get it, then use Januscape to escape to the host.
ITScape (June 2026) was the first publicly demonstrated guest-to-host escape on KVM/ARM64, exploiting a race condition in the virtual interrupt controller. Januscape is the x86 counterpart to that research, and the two together mean guest-to-host escapes have now been publicly demonstrated on every major architecture KVM supports.
CVE-2026-46113, a separate but related shadow-paging use-after-free involving a similarly mismatched reverse-mapping structure, was fixed in the kernel back in May 2026, before Januscape was reported. That means this is the second shadow MMU use-after-free patched in the same legacy code path within about two months, which says something about how much latent risk was sitting in code that hardware-assisted paging had made most people stop thinking about.
What should you do?
1. Determine whether you are exposed
Ask three questions about any x86 KVM host you operate or rely on:
- Does it accept guest VMs from parties you do not fully trust, including customers on a shared platform?
- Is nested virtualization enabled or available to those guests?
- Is
/dev/kvmworld-writable on the host (relevant primarily for RHEL and similar distributions)?
To check whether nested virtualization is currently enabled:
# Intel
cat /sys/module/kvm_intel/parameters/nested
# AMD
cat /sys/module/kvm_amd/parameters/nested
A result of Y or 1 means nested virtualization is active.
To check the permissions on /dev/kvm:
ls -l /dev/kvm
2. Patch the host kernel
The definitive fix is updating to one of the patched stable releases listed above, or confirming that your distribution's backport includes kernel commit 81ccda30b4e8. Because distribution version numbers often do not map directly to upstream stable releases, check your package changelog rather than relying on uname -r alone.
# Ubuntu / Debian
sudo apt-get update && sudo apt-get upgrade
# RHEL / Rocky / AlmaLinux
sudo dnf update kernel
# Amazon Linux
sudo dnf update kernel
# SUSE / openSUSE
sudo zypper update kernel-default
# Arch Linux
sudo pacman -Syu
Reboot to load the patched kernel, then verify:
uname -r
3. If you cannot patch immediately, disable nested virtualization
Removing nested virtualization from untrusted guests eliminates the attack path entirely, since it is what forces KVM back onto the vulnerable shadow MMU code.
# Intel
sudo rmmod kvm_intel
sudo modprobe kvm_intel nested=0
# AMD
sudo rmmod kvm_amd
sudo modprobe kvm_amd nested=0
To make this persistent across reboots, add options kvm_intel nested=0 (or options kvm_amd nested=0) to a file under /etc/modprobe.d/.
This will break any legitimate workloads that depend on nested virtualization, such as customers or internal teams running a hypervisor inside their own VM, so coordinate with those stakeholders before applying it broadly.
4. Restrict /dev/kvm permissions where applicable
On distributions where /dev/kvm ships world-writable, tighten the permissions so only users in an appropriate group (typically kvm) can access it, closing off the local privilege escalation path independent of the guest-to-host issue.
sudo chmod 660 /dev/kvm
sudo chown root:kvm /dev/kvm
Confirm your distribution's udev rules do not simply reset this on the next device event; a persistent udev rule change is usually needed rather than a one-time chmod.
5. Review nested virtualization offerings to customers
If your organization offers self-service nested virtualization as a product feature, this is a reasonable moment to review whether that feature needs to remain broadly available while patching rolls out across your fleet, or whether it can be temporarily scoped to trusted customers only.
Detection
The public proof-of-concept produces a specific, identifiable kernel panic. Watch for it in host-level logs:
# Check for the Januscape panic signature
journalctl -k | grep -i "pte_list_remove"
# Or in dmesg / kernel logs
dmesg | grep -E "kernel BUG.*mmu\.c"
The panic surfaces as a kernel BUG in arch/x86/kvm/mmu/mmu.c, specifically referencing pte_list_remove, associated with the qemu-kvm process or your platform's equivalent VMM process.
Because the exploit requires loading a kernel module inside the guest VM, host operators running managed VM platforms should also watch for unusual or unauthorized kernel module load activity inside customer-facing guests where that visibility is available, and treat repeated, unexplained host kernel panics tied to KVM as a signal warranting investigation rather than routine infrastructure noise.
No public exploit for the code-execution path exists at this time, so there is no equivalent detection signature to watch for beyond the panic associated with the DoS proof-of-concept. That may change if the withheld exploit or an independently developed one surfaces later.
A note on timing and severity
We want to be direct about something: this disclosure does not come with an active exploitation confirmation the way some of our recent coverage has. There is no evidence, as of this writing, of Januscape being used against production infrastructure outside of its authorized use in Google's kvmCTF program. That is a meaningfully different risk posture than a vulnerability with a public RCE exploit and confirmed in-the-wild activity.
That said, "no confirmed exploitation yet" is not the same as "low priority." A sixteen-year-old guest-to-host escape affecting the hypervisor technology underneath a large share of public cloud infrastructure, with a researcher-confirmed working path to host code execution that simply has not been published, is the kind of finding that tends to get independently rediscovered once attention is drawn to the affected code path. The same pattern played out with Dirty Frag and ITScape earlier this year: public proof-of-concept first, more capable exploitation following once the code path was under scrutiny.
Summary
| CVE | CVE-2026-53359 |
| Nickname | Januscape |
| Type | Use-after-free in KVM shadow MMU (guest-to-host VM escape) |
| Component | Linux kernel, KVM/x86 (Intel and AMD) |
| Discovered by | Hyunwoo Kim (@v4bel) |
| Introduced | August 2010 (kernel 2.6.36 era) |
| Patched (mainline) | Mid-to-late June 2026, commit 81ccda30b4e8 |
| Patched (stable releases) | July 4, 2026 |
| CVSS score | Not yet assigned by NVD |
| Requires | Root inside a guest VM; nested virtualization enabled on the host |
| Immediate impact | Host kernel panic (DoS), publicly demonstrated |
| Full RCE? | Confirmed working by the researcher; exploit withheld |
| Additional risk | LPE on distributions where /dev/kvm is world-writable (e.g., RHEL) |
| ARM64 affected? | No; see ITScape (CVE-2026-46316) separately |
| Public PoC? | Yes, DoS-only |
| Confirmed active exploitation? | No, beyond authorized use in Google's kvmCTF program |
| Immediate mitigation | Disable nested virtualization for untrusted guests; restrict /dev/kvm permissions |
| Full fix | Update to a patched kernel (7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260, or later) |
If you operate multi-tenant KVM infrastructure, offer nested virtualization to customers, or need help assessing your exposure across this and the related Dirty Frag and ITScape disclosures, get in touch. A guest-to-host escape sitting quietly in shared hypervisor infrastructure for sixteen years is exactly the kind of finding that deserves a fleet-wide check, not just a note in next quarter's patch cycle.