Linux KVM/x86 'Januscape' shadow-MMU use-after-free — guest-to-host VM escape on Intel and AMD (public PoC host-DoS; RCE withheld); fixed 6.1.177/6.6.144/6.12.95/6.18.38/7.1.3

cve · CVE-2026-53359

Coverage timeline

first 2026-07-09 → last 2026-08-08

Peak priority

high

2 high

Sources cited

4 hosts

Sections touched

trending-vulnerabilities, updates

Co-occurring entities

see Related entities below

ATT&CK techniques

pinned v19.2 · see below

Hunting pivots

ATT&CK techniques

T1068 T1611

Affected products

Linux Kernel (KVM/x86)

ATT&CK techniques

2 techniques observed across 2 entries — derived from entry metadata and body evidence, never asserted without a published entry behind it · pinned to MITRE ATT&CK v19.2 · compare on the matrix · Navigator layer (JSON)

Privilege Escalation TA0004

T1068Exploitation for Privilege Escalation×1

Adversaries may exploit software vulnerabilities in an attempt to elevate privileges. Exploitation of a software vulnerability occurs when an adversary takes advantage of a programming error in a program, service, or within the operating system software or kernel itself to execute adversary-controlled code. Security constructs such as permission levels will often hinder access to information and use of certain techniques, so adversaries will likely need to perform privilege escalation to include use of software exploitation to circumvent those restrictions.

Evidence: 2026-08-08/zapscape-cve-2026-64561-kvm-shadow-mmu-second-vm-escape · ATT&CK page ↗

T1611Escape to Host×2

Adversaries may break out of a container or virtualized environment to gain access to the underlying host. This can allow an adversary access to other containerized or virtualized resources from the host level or to the host itself. In principle, containerized / virtualized resources should provide a clear separation of application functionality and be isolated from the host environment.

Evidence: 2026-08-08/zapscape-cve-2026-64561-kvm-shadow-mmu-second-vm-escape · 2026-07-09/cve-2026-53359-januscape-kvm-x86-guest-to-host-vm-escape · ATT&CK page ↗

Story timeline

2026-08-08CVE-2026-64561 'Zapscape' — a second KVM shadow-MMU use-after-free reaches guest-to-host escape, and Belgium's CCB tells operators to patch immediately
updatesThe KVM shadow MMU yields a second guest-to-host escape, this one in the recursive zap path, with a public exploitation chain
2026-07-09CVE-2026-53359 — Linux KVM/x86 "Januscape": shadow-MMU use-after-free enables guest-to-host VM escape on Intel and AMD
trending-vulnerabilitiesJanuscape (CVE-2026-53359): 16-year-old KVM shadow-MMU UAF gives a guest root a host escape on both Intel and AMD

Where this entity is cited

trending-vulnerabilities1
updates1

Source distribution

github.com2 (40%)
bleepingcomputer.com1 (20%)
ccb.belgium.be1 (20%)
git.kernel.org1 (20%)

Co-occurring entities

Derived — referenced by the same focused operational entries (weekly summaries and report roundups don't count); ×N counts the shared entries.

Linux KVM/x86 'Zapscape' — use-after-free in the recursive shadow-MMU zap path gives guest-root-to-host escape (CVSS 8.8); needs nested virtualization, and on Intel EPT page-walk lengths 4 and 5 exposed to L1; fixed upstream 2abd5287f083×1
cveCVE-2026-64561

External references

NVD · cve.org · CISA KEV

All cited sources (5)

Entries about Linux KVM/x86 'Januscape' shadow-MMU use-after-free — guest-to-host VM escape on Intel and AMD (public PoC host-DoS; RCE withheld); fixed 6.1.177/6.6.144/6.12.95/6.18.38/7.1.3 (2)

2026-08-08 · view entry permalink →

HIGHCVE-2026-64561 +1updateNATOA1

CVE-2026-64561 'Zapscape' — a second KVM shadow-MMU use-after-free reaches guest-to-host escape, and Belgium's CCB tells operators to patch immediately

UPDATE · originally covered CVE-2026-53359 — Linux KVM/x86 "Januscape": shadow-MMU use-after-free enables guest-to-host VM escape on Intel and AMD (2026-07-09)

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).

Defender takeaway

the July entry's advice was to patch host kernels for one bug; the estate now needs both fixes, and the exposure question is no longer only "which kernel" but "which of my hosts hand nested virtualization to a workload that does not need it". For European public-sector and critical-infrastructure operators running KVM-backed private cloud or renting KVM capacity, nested virtualization is the single toggle that removes both bugs' reachability, and it is far more often enabled by default than actually required. Triage: exploitation of a shadow-MMU use-after-free surfaces on the host, not in the guest — an unexplained host kernel panic or oops correlated with one tenant's VM activity is the signal, and it is distinguishable from ordinary instability by that correlation: routine host crashes do not repeat against the same guest. Preserve the host for forensics rather than rebooting it back into service. Neither CCB nor the researcher reports in-the-wild exploitation of either CVE.

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.

Centre for Cybersecurity Belgium (CCB) 2026-08-07

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 — researcher write-up 2026-08-06

vulnerability08 Aug 04:47Zmulti-sourceOpen finding ↗

Sources: Centre for Cybersecurity Belgium (CCB) · V4bel — researcher write-up

2026-07-09 · view entry permalink →

HIGHCVE-2026-53359

CVE-2026-53359 — Linux KVM/x86 "Januscape": shadow-MMU use-after-free enables guest-to-host VM escape on Intel and AMD

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.

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).

BleepingComputer 2026-07-07

This is the first guest-to-host exploit research triggerable on both Intel and AMD

Hyunwoo Kim (V4bel) — researcher write-up + PoC 2026-07-07

vulnerability09 Jul 04:32Zmulti-sourceOpen finding ↗

Sources: BleepingComputer · Hyunwoo Kim (V4bel) — researcher write-up + PoC · Linux kernel upstream fix commit