16-Year-Old Linux KVM Flaw 'Januscape' Lets Guest VMs Escape to the Host on Intel and AMD Systems
A 16-year-old use-after-free bug in Linux's KVM hypervisor, dubbed Januscape and rated CVSS 8.8, lets malicious VMs escape to the host on both Intel and AMD systems; OVHcloud patched roughly a million VMs across its fleet in an 11-day campaign.
Editor's Note ·
- Correction:
- The article attributes the CVSS 8.8 score to "the National Vulnerability Database." The NVD page for CVE-2026-53359 states its own assessment is "not yet provided" (Base Score: N/A under the NIST/NVD row); the 8.8 figure shown on that page is a self-submitted score from the CNA (kernel.org), not an NVD analyst score. The number itself is accurate and independently corroborated by SUSE's own 8.8 (CVSS v3.1) rating, but the attribution to NVD as the scoring body is imprecise.
- Clarification:
- The article quotes CSO Online as describing ITScape as "a separate ARM64 KVM guest-to-host escape vulnerability disclosed by the same researcher in the previous month." This exact wording does not appear in the CSO Online article, which instead states Hyunwoo Kim "also disclosed a different KVM guest-to-host escape vulnerability dubbed ITScape (CVE-2026-46316) last month that works on ARM64 architecture." The underlying fact is accurate; the quotation marks misrepresent a paraphrase as verbatim text.
- Clarification:
- The article quotes the Cloud Security Alliance as stating CVE-2026-46113 "must be patched alongside CVE-2026-53359" for complete remediation. This exact phrase does not appear in the CSA research note, which conveys the same point in different words (an administrator who patches CVE-2026-53359 but misses the CVE-2026-46113 companion fix "remains exposed to the same underlying reuse flaw"). The underlying fact is accurate and independently corroborated elsewhere; the quotation marks misrepresent a paraphrase as verbatim text.
Overview
A use-after-free vulnerability in the Linux kernel’s KVM hypervisor that has existed since 2010 lets a malicious guest virtual machine escape to the host it runs on, affecting both Intel and AMD x86 systems, according to The Hacker News and Threat-Modeling.com. The flaw, tracked as CVE-2026-53359 and nicknamed “Januscape,” carries a CVSS base score of 8.8 (“high”), according to the National Vulnerability Database.
What We Know
Security researcher Hyunwoo Kim, who uses the online handle V4bel, found and reported the bug through Google’s kvmCTF, a program that offers “up to $250,000 for full guest-to-host escapes,” according to Threat-Modeling.com. Kim dubbed the flaw “Januscape,” according to CSO Online, which also notes that Google runs the bounty program in part because KVM underlies both Google Cloud and Android infrastructure.
The root cause lies in KVM’s shadow memory management unit code, which “matched candidate pages by memory address alone, without verifying that the page being reused actually matched the tracking role it was being assigned,” according to the Cloud Security Alliance. TuxCare describes the mechanism in similar terms: “a malicious guest can drive KVM into reusing a cached shadow page that no longer matches the mapping being built,” tracing the bug to a missing role comparison in the kernel function kvm_mmu_get_child_sp(), which checked guest frame numbers but not the page’s role, allowing stale reverse-map entries to persist after the original page was freed.
Kim described the practical danger in stark terms: “With guest-side actions alone, an attacker can compromise the host that runs their VM. For example, an attacker who has rented just a single instance on a public cloud could panic the host kernel to take down every other tenant VM on the same physical machine (DoS), or run code with root privilege on the host to take over the host and all the guests on it (RCE),” according to CSO Online.
The vulnerable code was introduced in August 2010 through commit 2032a93d66fa, part of Linux kernel 2.6.36, and has persisted ever since in shadow-paging logic shared by Intel and AMD x86 implementations, according to The Hacker News and the National Vulnerability Database. A public proof-of-concept reliably crashes the host kernel, but Kim has withheld the full exploit chain that would achieve root code execution on the host, according to Threat-Modeling.com and the Cloud Security Alliance.
The primary fix, commit 81ccda30b4e8, was written by KVM maintainer Paolo Bonzini and adds a check on both the page’s role and guest frame number before allowing shadow-page reuse, according to The Hacker News. It merged into the mainline kernel in June 2026, and fixed stable versions — 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, and 5.10.260 — were released on July 4, 2026, the same day the flaw was published in the National Vulnerability Database, according to The Hacker News. Patching the primary flaw alone does not fully close the hole: a companion bug tracked separately as CVE-2026-46113, fixed by commit 0cb2af2ea66a that landed May 28, 2026, addresses a related use-after-free in the same shadow-paging reuse logic and “must be patched alongside CVE-2026-53359” for complete remediation, according to the Cloud Security Alliance.
Januscape is not the only KVM guest-escape bug Kim has disclosed recently. A separate vulnerability, CVE-2026-46316 and nicknamed “ITScape,” is described as “a separate ARM64 KVM guest-to-host escape vulnerability disclosed by the same researcher in the previous month,” according to CSO Online — a distinct flaw from the Intel/AMD-focused companion fix CVE-2026-46113.
CVSS scoring for Januscape has varied by vendor: Red Hat rates it 7.0 (“Important”), while SUSE assigns 8.8 under CVSS v3.1 and 9.3 under CVSS v4.0, according to the Cloud Security Alliance. On some Linux distributions, including RHEL, world-writable permissions on the /dev/kvm device (0666) can turn Januscape into a local privilege-escalation path even without nested virtualization, according to CSO Online.
The vulnerability’s real-world remediation cost became visible at OVHcloud, which detailed its own patching campaign in a company engineering blog post. The French cloud provider said the flaw touched “tens of thousands of hypervisor hosts” running “approximately one million virtual machines” across its global fleet, and that it completed the patch rollout in 11 days using a “follow-the-sun” approach across regions, according to OVHcloud. The company said it opted for “unilateral patching with controlled impact” rather than waiting for individual customer sign-off, having judged a zero-impact rollout impossible at that scale, according to OVHcloud. OVHcloud reported that on the first night of patching, “approximately 20 to 30 hosts out of 6,000 did not come back on their own,” and that one region, GRA6, had “almost 90,000 non-contacted customers” during the rollout, according to OVHcloud.
What We Don’t Know
Reports disagree on the exact calendar day the primary fix merged into the mainline kernel, placing it broadly in June 2026 without a consistent specific date. Kim has not published the full guest-to-host code-execution exploit chain, so the real-world severity beyond the demonstrated kernel-panic proof-of-concept remains unconfirmed outside the researcher’s own private testing, according to Threat-Modeling.com and the Cloud Security Alliance.