CVE-2026-53359, Linux KVM/x86 "Januscape": shadow-MMU use-after-free enables guest-to-host VM escape on Intel and AMD
Januscape (CVE-2026-53359): 16-year-old KVM shadow-MMU UAF gives a guest root a host escape on both Intel and AMD
Defender actions
- Patch KVM host kernels so they carry upstream commit 81ccda30b4e8 (2026-06-16), confirm your distro's stable kernel includes the backport; this is a host-kernel fix with no guest-side workaround or config toggle.
- On multi-tenant KVM estates, treat any unexplained host kernel panic/reboot that co-occurs with a single tenant's VM activity as a possible exploitation signal and preserve the host for forensics.
- Patch KVM host kernels so they carry both fixes (Januscape commit 81ccda30b4e8 and Zapscape commit 2abd5287f083); there is no guest-side mitigation for either, so a patched guest on an unpatched host is still exposed.
- Turn nested virtualization off for every tenant and workload that does not explicitly need it; where it must stay on for Intel guests, restrict exposure of EPT page-walk lengths 4 and 5 to L1, which is Zapscape's stated precondition.
Analysis
Researcher Hyunwoo Kim (V4bel) disclosed Januscape (CVE-2026-53359), a use-after-free in the shadow-MMU emulation of KVM/x86 (arch/x86/kvm/mmu/mmu.c) whose root cause traces to a 2010 commit, roughly 16 years dormant before the fix landed upstream on 16 June 2026 (BleepingComputer, 2026-07-07). The bug fires when kvm_mmu_get_child_sp() reuses a shadow page without comparing its role, producing a mismatched direct/indirect flag and an incorrect GFN computation; orphaned rmap entries survive memslot deletion and are later dereferenced after the backing memory is freed (V4bel, 2026-07-07). The upstream fix is commit 81ccda30b4e8 (16 June 2026); the researcher gives the vulnerable range as commit 2032a93d66fa (2010-08-01) through that fix (kernel.org, 2026-06-16; V4bel, 2026-07-07).
This is a genuine guest-to-host escape: a root user inside a KVM guest can trigger the UAF from purely guest-side actions, on both Intel and AMD hosts, the researcher calls it "the first guest-to-host exploit research triggerable on both" vendors (V4bel, 2026-07-07). Januscape was submitted as a live 0-day against Google's kvmCTF program. A public PoC that panics the host kernel (a denial of service against every co-tenant on the same physical host) is released; a full working host-compromise/RCE exploit exists but the researcher is deliberately withholding it (BleepingComputer, 2026-07-07). Mapped to T1611 Escape to Host.
Cited evidence
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).
This is the first guest-to-host exploit research triggerable on both Intel and AMD
These two vulnerabilities can let an attacker run commands on the host by escaping the guest virtual machine, this can lead to a full system compromise since the attacker can escape the virtual environment.
This vulnerability can only be exploited by attackers with root privileges and systems with Intel architecture need both EPT page walk length 4 and 5 exposed to L1.
Distributions like RHEL can allow an unprivileged user to gain root privileges.
can be triggered on Intel without any particular constraint as long as nested virtualization is enabled, but Zapscape requires that both EPT page walk length 4 and 5 be exposed to L1 on Intel. On AMD there is no such constraint.
Updates1
Januscape has a sibling. Zapscape (CVE-2026-64561) was assigned on 2026-08-04 and is a use-after-free in the same KVM/x86 shadow MMU, but in a different path: where Januscape came from shadow-page role confusion, Zapscape fires when a guest using nested virtualization makes KVM recursively zap a root shadow page that is still in use during MMU page-quota reclaim, leaving KVM handling a fault on a root that has already been invalidated (V4bel, 2026-08-06). The upstream fix, commit 2abd5287f083, moves the stale-root check after make_mmu_pages_available() (V4bel, 2026-08-06).
Belgium's Centre for Cybersecurity turned the pair into a single operational instruction on 2026-08-07, publishing a "Patch Immediately" advisory that treats both CVEs together, scores each CVSS 8.8 (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), and states that they "can let an attacker run commands on the host by escaping the guest virtual machine, this can lead to a full system compromise since the attacker can escape the virtual environment" (CCB, 2026-08-07).
Two preconditions decide who is actually exposed, and they differ between the two bugs. Januscape "can be triggered on Intel without any particular constraint as long as nested virtualization is enabled, but Zapscape requires that both EPT page walk length 4 and 5 be exposed to L1 on Intel. On AMD there is no such constraint" (V4bel, 2026-08-06); CCB states Zapscape "can only be exploited by attackers with root privileges and systems with Intel architecture need both EPT page walk length 4 and 5 exposed to L1" (CCB, 2026-08-07). The guest-root precondition sounds like a high bar and often is not: CCB adds that "Distributions like RHEL can allow an unprivileged user to gain root privileges," and on rented cloud instances guest root is simply what the tenant has (CCB, 2026-08-07). The researcher's current public demonstration runs on AMD nested SVM/NPT (V4bel, 2026-08-06).
Sources5
Revision history
- Published 2026-07-09T0409Z-intel
- Update 2026-08-08T0409Z-intel
A second use-after-free in the KVM/x86 shadow MMU, Zapscape (CVE-2026-64561), was assigned on 2026-08-04 and carried to European constituents by Belgium's Centre for Cybersecurity on 2026-08-07 in a "Patch Immediately" advisory that covers it alongside Januscape (CVE-2026-53359), the 2010-vintage bug this pipeline covered on 2026-07-09. Both are CVSS 8.8 and both let a root user inside a guest run commands on the host. Zapscape lives in the recursive zap path that runs during MMU page-quota reclaim, needs nested virtualization, and on Intel additionally requires EPT page-walk lengths 4 and 5 exposed to L1; on AMD there is no such constraint. CCB notes RHEL-class distributions can let an unprivileged guest user reach guest root in the first place.
Changed: actions affected_products cves evidence regions sources tags techniques body
AI-generated · no human review · this permalink is the shareable record for the finding · verify operationally critical claims against the linked primary source.