CVE-2026-53359 Januscape: 16-Year-Old Linux KVM VM Escape

This week in our InSEKurity of the Week series: a guest-to-host virtual machine escape in the Linux kernel’s KVM hypervisor — nicknamed Januscape — that had been sitting in the shadow MMU code since 2010, roughly 16 years, before researcher Hyunwoo Kim (@v4bel) surfaced it as a zero-day in Google’s kvmCTF program. The bug is a use-after-free (CWE-416) in how KVM reuses shadow page-table structures: a root user inside a guest VM, on a host that exposes nested virtualization, can corrupt the host kernel’s shadow-page bookkeeping. The public proof-of-concept panics the host — taking down every other tenant on that machine — and the researcher describes an unreleased exploit that turns the same primitive into arbitrary code execution as root on the host. What makes Januscape unusually dangerous is that it is the first KVM escape known to trigger on both Intel and AMD x86, and KVM is the hypervisor underneath most of the Linux virtualization world — public clouds, OpenStack, Proxmox, and countless self-hosted fleets. If you run multi-tenant KVM with untrusted guests, this belongs at the top of your queue.

🚨 Summary

CVE ID: CVE-2026-53359 (Januscape) — with coupled fix CVE-2026-46113
CVSS 3.1 Score: 8.8 (High) — as rated by SUSE; NVD base score pending at time of writing
CVSS 4.0 Score: 9.3 (Critical) — SUSE rating
CWE: CWE-416 (Use After Free) in the KVM shadow MMU
Affected Software: Linux kernel KVM (kvm, kvm-intel, kvm-amd) on x86-64 — Intel and AMD
Attack Vector: Local to the host, but reachable from an untrusted guest VM — a guest triggers host-side memory corruption
Authentication Required: Root inside the guest (the default privilege level a tenant has in their own VM); host requires nested virtualization exposed to the guest
User Interaction: None
Impact: Guest-to-host escape — host kernel panic (DoS for all co-located tenants) or arbitrary code execution as root on the host, fully compromising every guest on the machine
Patch Status: ✅ Available — fix merged mainline June 19, 2026 (commit 81ccda30b4e8); stable kernels released July 4, 2026
Published: July 6, 2026 (public disclosure by the researcher)
Exploitation Status: Demonstrated as a zero-day in Google’s kvmCTF; public PoC causes host panic, full-RCE exploit held privately by the researcher; no confirmed in-the-wild attacks reported
CISA KEV: ❌ Not listed at time of writing

🖥️ What is Linux KVM?

KVM (Kernel-based Virtual Machine) is the virtualization layer built into the mainline Linux kernel. It turns the Linux kernel itself into a type-1-style hypervisor, using the hardware virtualization extensions in modern CPUs (Intel VT-x, AMD-V) to run guest operating systems at near-native speed. KVM provides the low-level CPU and memory virtualization, while a userspace component — typically QEMU, or a lighter VMM like Cloud Hypervisor or Firecracker — provides device emulation and management. Orchestration layers such as libvirt, OpenStack, Proxmox VE, oVirt/RHV, and the control planes of every major public cloud sit on top of it.

KVM is, in practical terms, the workhorse hypervisor of the Linux and cloud ecosystem. When you spin up a Linux VM on a hyperscaler, a VPS provider, or an on-prem OpenStack cluster, there is a very good chance a KVM host is running your guest — frequently alongside other customers’ guests on the same physical machine. That multi-tenant reality is exactly what makes a guest-to-host escape a systemic risk rather than a single-machine one: the security boundary between VMs is the hypervisor, and Januscape punches through it.

Typical Use Cases

Public cloud compute: the IaaS layer of hyperscalers and VPS providers running customer Linux/Windows guests.
Private cloud and virtualization platforms: OpenStack, Proxmox VE, oVirt/RHV, and libvirt-managed KVM fleets.
Nested virtualization: CI runners, container-in-VM sandboxes, security research labs, and “VMs inside VMs” for testing — the exact feature Januscape depends on.
Developer and desktop virtualization: GNOME Boxes, virt-manager, and QEMU/KVM on Linux workstations.
Confidential and isolation workloads: sandboxing untrusted code inside a VM boundary — the trust assumption Januscape violates.

Because tenants routinely have full root inside their own guests — that is the product, not a misconfiguration — the “attacker needs root in the guest” precondition is not a barrier in a multi-tenant cloud. It is the baseline the attacker already starts from.

🔍 Technical Analysis

Vulnerability Description

Januscape (CVE-2026-53359) is a use-after-free in the Linux KVM shadow MMU — the software layer KVM uses to translate guest memory addresses into host-authorized memory when hardware-assisted paging cannot be used directly. KVM maintains host-side structures called shadow pages, each tagged with a role describing its type and purpose (page-table level, direct vs. indirect mapping, and so on). The bug is that a code path reused an existing shadow page by matching only the guest frame number (GFN) while ignoring the page’s role. Two structurally different shadow pages can share the same GFN yet do completely different jobs — so KVM would sometimes reuse the wrong kind of page.

The name Januscape evokes Janus, the two-faced Roman god: a single shadow page presenting two incompatible “faces” (roles) to the host. When the mismatch occurs, a stale reverse-map (rmap) entry is left pointing at a structure KVM later frees, and any subsequent operation that walks that reverse map dereferences memory inside the freed page — a classic use-after-free that leads either to a host panic or, when carefully steered, to controlled memory corruption and code execution on the host.

Root Cause Analysis

Shadow-page reuse keyed on GFN only (CWE-416): kvm_mmu_get_child_sp() looked up an existing shadow page by guest frame number without also comparing the page’s full role. When a guest mapping transitioned — for example from a direct large 2 MB page (role.direct = 1) to a non-direct 4 KB page-table path (role.direct = 0) — KVM reused a page whose role no longer matched the mapping being built.
Type confusion between shadow-page roles: the two roles maintain their reverse-map bookkeeping differently. Reusing the wrong role means KVM later computes the wrong frame number during teardown and fails to remove the reverse-map entry for the structure.
Dangling reverse-map entry → use-after-free: when the shadow page is freed, the stale rmap entry survives, still pointing into the freed page. The next operation that walks that reverse map dereferences freed memory — the use-after-free primitive at the heart of Januscape.
Reachable only via the software shadow MMU: modern hosts normally use hardware nested paging (Intel EPT / AMD NPT), which does not exercise this code. KVM falls back to the legacy software shadow MMU primarily when it exposes nested virtualization to a guest — which is why nested virt is the trigger and the exposure vector.
Architecture-independent code path: the shadow MMU is shared logic above the Intel/AMD split, so the same bug fires on both vendors — making Januscape the first KVM escape known to trigger on Intel and AMD alike.
Long-lived latent bug: the flawed reuse logic was introduced back in commit 2032a93d66fa around August 2010 (the 2.6.36 era) and went unnoticed for roughly 16 years.

Attack Vector

The exploitation flow is entirely local to the guest — no network payload, no host credentials. The snippet below is illustrative only; it describes the shape of the attack for defenders and does not contain a working Januscape exploit.

# Step 1: The attacker already holds root inside their own guest VM.
# In a multi-tenant cloud this is normal tenant access, not a compromise:
# you get root in the OS you rented. No host credentials are involved.
id   # uid=0(root) -- inside the guest, by design

# Step 2: Confirm the host exposes nested virtualization to this guest.
# Januscape only reaches the vulnerable software shadow MMU when nested
# virt is available, so the guest checks for /dev/kvm and VMX/SVM flags.
ls -l /dev/kvm
grep -E -o 'vmx|svm' /proc/cpuinfo | sort -u   # vmx=Intel, svm=AMD nested

# Step 3: From inside the guest, drive KVM's shadow MMU into reusing a
# shadow page whose ROLE no longer matches -- e.g. by forcing a guest
# mapping to transition between a 2MB direct page and a 4KB page-table
# path so KVM matches on GFN alone and picks the wrong-role page.
#   -> A real PoC does this from a loadable kernel module in the guest.
#      Illustrative placeholder only; NOT a functional exploit.

# Step 4: The mismatch leaves a stale reverse-map entry pointing into a
# shadow page KVM later frees. A subsequent rmap walk on the HOST
# dereferences freed memory (use-after-free).
#   -> Public PoC outcome: host kernel panic (DoS for all co-tenants).
#   -> Researcher's unreleased exploit: shape the freed object to gain
#      arbitrary code execution as root ON THE HOST.

A simplified view of where the boundary breaks:

Guest VM (attacker = root in guest)            KVM Host kernel (shadow MMU)
   |                                                     |
   |  force guest mapping transition                     |
   |  (2MB direct  <->  4KB non-direct)                  |
   |---------------------------------------------------->|  kvm_mmu_get_child_sp()
   |                                                     |  matches shadow page by GFN,
   |                                                     |  IGNORES role -> reuses wrong
   |                                                     |  role.direct page (type confusion)
   |                                                     |
   |  trigger teardown of the mismatched page            |
   |---------------------------------------------------->|  wrong GFN computed at cleanup;
   |                                                     |  stale reverse-map (rmap) entry
   |                                                     |  left behind after free
   |                                                     |
   |  cause any later rmap walk                          |
   |---------------------------------------------------->|  dereference into FREED page
   |                                                     |  -> use-after-free
   |                                                     |     * panic  = DoS all tenants
   |<-- host down, or attacker code runs as root --------<|     * groomed = RCE as root
   v                                                     v

Exploitation in the Wild

Januscape was surfaced through Google’s kvmCTF, the hypervisor bug-bounty program that pays out for demonstrated guest-to-host escapes on a hardened Google-run KVM host (full escapes are rewarded up to $250,000). It was submitted as a zero-day.
The public proof-of-concept reliably triggers a host kernel panic — a denial of service that takes down the host and, with it, every other guest on the same physical machine.
The researcher states a separate, unreleased exploit converts the same use-after-free into arbitrary code execution as root on the host, i.e. a full escape. That exploit has not been published.
At the time of writing there is no confirmed exploitation in the wild and the CVE is not in the CISA KEV catalog — but a 16-year-old, cross-vendor VM escape with a working public panic PoC is exactly the kind of bug that attracts weaponization once the details are studied.
Januscape is the third KVM shadow-MMU disclosure from the same researcher in two months, following Dirty Frag (May 2026) and ITScape (June 2026) — a pattern that suggests this code is under active scrutiny and more may follow.

Post-Exploitation Impact

Host denial of service: the public PoC alone panics the host kernel, killing every co-located tenant VM — a cross-tenant availability event from a single malicious guest.
Full host compromise: the researcher’s private exploit runs code as root on the host, giving control of the hypervisor itself.
Cross-tenant data access: once you own the host, you own the memory and disks of every guest on that machine — a catastrophic breach of the tenant isolation cloud customers rely on.
Persistence at the hypervisor layer: code running on the host can survive guest reboots and rebuilds, and is far harder for tenants to detect than in-guest malware.
Lateral movement across the fleet: a compromised host is a launch point into the provider’s management network and adjacent hosts.
Collapse of the VM trust boundary: any workload that relied on “it’s isolated in a VM” — sandboxes, CI runners, confidential workloads — loses that guarantee on an unpatched host.

⚠️ Impact Assessment

Immediate Impact

The VM isolation boundary is broken: on an unpatched, nested-virt-exposing host, a guest can escape to the host — the single assumption multi-tenant clouds are built on.
Prerequisite is the baseline, not a hurdle: “root in the guest” is exactly what a paying tenant has; the only additional condition is that the host exposes nested virtualization.
Cross-vendor: unlike prior KVM escapes, Januscape fires on both Intel and AMD, so mixed fleets get no free pass on either architecture.
Working public DoS today: even without the private RCE exploit, the public PoC can crash hosts and take down unrelated tenants.
Ubiquitous software: KVM is the default Linux hypervisor and underpins a huge share of cloud and on-prem virtualization.

Affected Versions

Component	Vulnerable	Fixed
Linux mainline (KVM x86 shadow MMU)	Introduced ~2.6.36 (commit `2032a93d66fa`, Aug 2010)	Fixed by commit `81ccda30b4e8`, merged June 19, 2026
Stable 7.1.x	< 7.1.3	7.1.3
Stable 6.18.x	< 6.18.38	6.18.38
Stable 6.12.x (LTS)	< 6.12.95	6.12.95
Stable 6.6.x (LTS)	< 6.6.144	6.6.144
Stable 6.1.x (LTS)	< 6.1.177	6.1.177
Stable 5.15.x (LTS)	< 5.15.211	5.15.211
Stable 5.10.x (LTS)	< 5.10.260	5.10.260

Both fixes are required. CVE-2026-46113 (commit 0cb2af2ea66a) closed the wrong-frame-number case earlier; CVE-2026-53359 (Januscape, commit 81ccda30b4e8) closes the wrong-role case. Applying the earlier patch alone does not close Januscape — verify your kernel carries both commits, not just a build date. Distribution kernels backport fixes to their own package versions, so always cross-reference your vendor’s advisory (Red Hat, SUSE, Ubuntu, Debian) for the exact fixed package.

Affected Environments

Multi-tenant KVM clouds and VPS providers: the highest-risk environment — untrusted tenants with guest root sharing physical hosts.
Hosts that expose nested virtualization: OpenStack/Proxmox setups, CI/CD runners, and labs that enable nested virt for tenants are directly in the blast radius.
On-prem virtualization fleets: OpenStack, Proxmox VE, oVirt/RHV, and libvirt-managed KVM hosts running any untrusted or semi-trusted guests.
Confidential-computing and sandboxing use cases: anything whose security model is “it’s contained in a VM.”
Mixed Intel/AMD estates: no architecture is exempt, so partial-fleet reasoning does not apply.

Attacker Profiles

Malicious cloud tenants: an attacker who simply rents a VM legitimately already meets the guest-root precondition.
Initial-access brokers and ransomware crews: a foothold in one guest that escalates to the host yields control of every neighbor — extremely high value.
APT / espionage actors: hypervisor-level persistence and cross-tenant memory access is a top-tier intelligence capability.
CTF / bug-bounty researchers: kvmCTF explicitly incentivizes exactly this class of escape, so mature exploit knowledge exists.
Insider threats in shared infrastructure: anyone with a legitimate guest on a shared host can attempt the escape.

🛡️ Mitigation Strategies

Immediate Actions (Priority 1) ⚡

Patch the host kernel to a fixed version and reboot (or apply your distro’s live-patch). The host kernel is what must be fixed — guests are irrelevant to the fix:

# Check the running host kernel version:
uname -r

# Update via your distribution's package manager, then reboot into
# the fixed kernel. Confirm your vendor's advisory lists a build that
# includes BOTH CVE-2026-53359 and CVE-2026-46113.
sudo apt update && sudo apt install --only-upgrade linux-image-$(uname -r | sed 's/-generic//')-generic   # Debian/Ubuntu
sudo dnf update kernel                                                                                     # RHEL/Fedora/Rocky/Alma
sudo zypper patch                                                                                          # SUSE/openSUSE
sudo reboot

Verify the fixed version is actually running after reboot — compare against the fixed stable kernels (7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260) or your vendor’s fixed package build:

# After reboot, confirm the kernel meets or exceeds the fixed version:
uname -r

# On distro kernels, check the changelog for both CVE IDs to be sure
# the backport is present (not just a newer build number):
rpm -q --changelog kernel | grep -E 'CVE-2026-53359|CVE-2026-46113'   # RPM-based
zcat /usr/share/doc/linux-image-*/changelog.Debian.gz 2>/dev/null | grep -E 'CVE-2026-53359|CVE-2026-46113'   # Debian/Ubuntu

If you cannot patch immediately, disable nested virtualization for untrusted guests. This removes the shadow-MMU code path that Januscape abuses. Note: this only protects hosts that do not need to offer nested virt — it is a stopgap, not a fix:

# Disable nested virtualization on the host (Intel):
echo 'options kvm_intel nested=0' | sudo tee /etc/modprobe.d/disable-nested.conf

# Or on AMD:
echo 'options kvm_amd nested=0' | sudo tee /etc/modprobe.d/disable-nested.conf

# Apply by reloading the module (evacuate/stop guests first) or reboot,
# then verify it now reports N:
cat /sys/module/kvm_intel/parameters/nested   # -> should read N (or 0)
cat /sys/module/kvm_amd/parameters/nested     # -> should read N (or 0)

Restrict access to /dev/kvm to trusted accounts and the kvm group so that only sanctioned workloads can create VMs on a host:
```
# Inventory who can reach /dev/kvm and tighten group membership:
ls -l /dev/kvm
getent group kvm
```
Prioritize hosts running untrusted or semi-trusted guests. Multi-tenant hosts and any host exposing nested virt to tenants are the ones to patch first.

Detection Measures 🔍

There are no vendor CVE IoCs for Januscape (it is a memory-corruption bug, not a network exploit). Focus on host-side crash and instability signals — the public PoC’s signature is a host kernel panic referencing the KVM MMU.

# 1) Hunt for KVM/MMU-related oopses, panics, and use-after-free reports
#    in the host kernel log and journal -- the public PoC panics here.
sudo dmesg -T | grep -E -i 'kvm|mmu|use-after-free|BUG:|general protection|Oops'
sudo journalctl -k -b -1 --no-pager | grep -E -i 'kvm|mmu|BUG:|panic'

# 2) If KASAN is enabled on a monitored/canary host, a use-after-free in
#    the shadow MMU will be reported explicitly -- treat any such hit as
#    a high-priority signal of Januscape-style activity.
sudo dmesg -T | grep -E -i 'KASAN|use-after-free.*(mmu|kvm|rmap)'

# 3) Correlate unexplained host crashes/reboots with tenant activity.
#    A guest that repeatedly precedes host panics is a strong lead.
last -x reboot shutdown | head -20
sudo journalctl --list-boots | tail -10

Additional hunting:

Alert on unexpected host reboots or kernel panics on virtualization hosts, especially clusters of them across a fleet.
Enable kdump/crash collection on KVM hosts so panics are captured for analysis rather than lost on reboot.
On sensitive or canary hosts, run KASAN-enabled kernels to catch use-after-free conditions with precise stack traces.
Watch for guests that load custom kernel modules and immediately precede host instability.
Ship host kernel logs to your SIEM and alert on kvm/mmu oops signatures.

Long-term Security Improvements

Fast-track patch SLAs for hypervisor hosts: a VM-escape CVE deserves an emergency-change window, not the routine kernel cadence — the blast radius is every tenant on the box.
Minimize nested virtualization exposure: enable nested virt only where a workload genuinely requires it, and never by default for untrusted tenants.
Adopt live kernel patching: KernelCare, kpatch, or Ubuntu Livepatch let you close hypervisor bugs without draining and rebooting every host.
Segment the virtualization control plane: keep host management networks isolated so a host compromise does not immediately reach the orchestration layer.
Assume-breach for the hypervisor: rehearse detecting and responding to a host-level compromise, including cross-tenant impact and evidence preservation.
Track the shadow-MMU bug cluster: Dirty Frag, ITScape, and Januscape came from the same code in quick succession — watch that subsystem for follow-on CVEs and keep kernels current.

🎯 Why is this Critical?

It breaks VM isolation: guest-to-host escape defeats the core security boundary that multi-tenant virtualization depends on.
The precondition is the product: “root in the guest” is what every cloud tenant already has; only nested virt on the host is additionally required.
Cross-vendor reach: the first KVM escape known to work on both Intel and AMD, so no architecture is safe by default.
A working public DoS exists now: the panic PoC can crash hosts and take out unrelated tenants even before the private RCE exploit spreads.
Full host takeover is on the table: the researcher’s unreleased exploit runs code as root on the host, exposing every co-located guest’s memory and disks.
Enormous installed base: KVM underpins hyperscalers, VPS providers, OpenStack, and Proxmox — the reach is measured in a large fraction of the world’s Linux VMs.
A 16-year latent bug in a hot subsystem: the third shadow-MMU disclosure in two months signals ongoing research and likely more to come.

🚀 Timeline and Disclosure

~August 2010 — The flawed shadow-page reuse logic is introduced in commit 2032a93d66fa (kernel 2.6.36 era), beginning a ~16-year latent window.
May 2026 — Related shadow-MMU flaw CVE-2026-46113 (wrong-frame-number case) is fixed via commit 0cb2af2ea66a; the same researcher discloses Dirty Frag.
June 2026 — The researcher discloses ITScape, another KVM shadow-MMU issue.
2026-06-19 — The Januscape fix (wrong-role case) is merged into mainline Linux as commit 81ccda30b4e8.
2026-07-04 — Fixed stable kernels are released: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, 5.10.260.
2026-07-06 (CW28) — Researcher Hyunwoo Kim (@v4bel) publicly discloses Januscape (CVE-2026-53359) with a host-panic PoC; security press amplifies the guest-to-host escape.

🔗 Resources and References

CVE: CVE-2026-53359 — and coupled fix CVE-2026-46113
NVD: NVD — CVE-2026-53359
CWE: CWE-416: Use After Free
Linux mainline fix: commit 81ccda30b4e8 (Januscape) and 0cb2af2ea66a (CVE-2026-46113)
CISA KEV Catalog: Known Exploited Vulnerabilities (not listed at time of writing)

💼 SEKurity Supports You

Januscape is a hard reminder that the virtual machine boundary is only as strong as the hypervisor beneath it — and that “it runs in a VM” is a trust assumption, not a guarantee. A single use-after-free in code that had shipped since 2010 lets a tenant who is simply doing what tenants do — being root in their own guest — reach for control of the host and every neighbor on it. We help organizations reason about exactly this kind of shared-infrastructure risk: mapping which hosts expose nested virtualization, validating that hypervisor kernels genuinely carry both required fixes (not just a newer build number), and stress-testing whether a host-level compromise would even be noticed before it became a cross-tenant breach. Our infrastructure and large-scale penetration testing probe the isolation boundaries — virtualization, containerization, and tenancy — that modern cloud and on-prem estates quietly depend on.

Our Services

Penetration Testing: Web applications, mobile apps (Android & iOS), SAP systems, Active Directory
Large-Scale Attacks: Perimeter testing, IT infrastructure testing, Red Team engagements
Security Awareness: Phishing campaigns, hacking demonstrations

Act now — before attackers do.

Contact:

🌐 Website: www.sekurity.de

📧 Inquiries: www.sekurity.de/kontakt

📱 LinkedIn: SEKurity GmbH

Your SEKurity Team — Your Trusted Adversaries

The security of your virtualization infrastructure is our drive.

InSEKurity of the Week (CW28/2026): Linux KVM Guest-to-Host VM Escape -- Januscape (CVE-2026-53359)