--- schema: 1 kind: vulnerability title: > CVE-2026-53359 — Linux KVM/x86 "Januscape": shadow-MMU use-after-free enables guest-to-host VM escape on Intel and AMD headline: > Januscape (CVE-2026-53359): 16-year-old KVM shadow-MMU UAF gives a guest root a host escape on both Intel and AMD summary: > Januscape (CVE-2026-53359) is a use-after-free in the KVM/x86 shadow-MMU emulation (arch/x86/kvm/mmu/mmu.c) that lay dormant in the Linux kernel for ~16 years and lets a root user inside any KVM guest escape to the host on both Intel and AMD. A public PoC panics the host kernel (DoS against every co-tenant); a working host-RCE exploit exists but is withheld. Fixed upstream 2026-06-16 — patch KVM host kernels to the fixed trains now; there is no guest-side mitigation. discovered_at: "2026-07-09T04:32:59Z" updated_at: "2026-08-08T04:47:00Z" event_date: 2026-07-07 run_id: 2026-07-09T0409Z-intel priority: high immediate_action: null tags: - vulnerabilities - lpe - priv-esc - poc-public - patch-available - cloud regions: - global - europe sectors: - technology - public-sector - finance - telco entities: [] techniques: - T1611 - T1068 affected_products: - Linux Kernel (KVM/x86) cves: - id: CVE-2026-53359 cvss: "8.8" epss: null type: memory-corruption vector: local auth: admin-required status: - poc-public - patch-available affected: "Linux KVM/x86 hosts before the fix, on Intel and AMD" fixed: upstream commit 81ccda30b4e8 (2026-06-16) - id: CVE-2026-64561 cvss: "8.8" epss: null type: memory-corruption vector: local auth: admin-required status: - poc-public - patch-available affected: > Linux KVM/x86 hosts before the fix; exploitable only where nested virtualization is enabled, and on Intel only where EPT page-walk lengths 4 and 5 are exposed to L1 fixed: > upstream commit 2abd5287f083 (carried in the stable trees CCB lists); confirm the running host kernel carries the backport sources: - url: "https://www.bleepingcomputer.com/news/linux/new-januscape-linux-kernel-flaw-allows-vm-escape-on-intel-amd-devices/" publisher: BleepingComputer date: 2026-07-07 role: primary - url: "https://github.com/V4bel/Januscape" publisher: Hyunwoo Kim (V4bel) — researcher write-up + PoC date: 2026-07-07 role: primary - url: "https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=81ccda30b4e8" publisher: Linux kernel upstream fix commit date: 2026-06-16 role: corroborating - url: "https://ccb.belgium.be/advisories/warning-vm-escape-vulnerabilities-kvm-patch-immediately" publisher: Centre for Cybersecurity Belgium (CCB) date: 2026-08-07 role: primary - url: "https://github.com/V4bel/Zapscape/blob/main/assets/write-up.md" publisher: V4bel — researcher write-up date: 2026-08-06 role: primary closed_sources: [] evidence: - quote: "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)." publisher: BleepingComputer - quote: This is the first guest-to-host exploit research triggerable on both Intel and AMD publisher: Hyunwoo Kim (V4bel) — researcher write-up + PoC - quote: "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." publisher: Centre for Cybersecurity Belgium (CCB) - quote: 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. publisher: Centre for Cybersecurity Belgium (CCB) - quote: Distributions like RHEL can allow an unprivileged user to gain root privileges. publisher: Centre for Cybersecurity Belgium (CCB) - quote: "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." publisher: V4bel — researcher write-up verification: multi-source sourcing_note: null confidence: high references: [] deep_dive: false deep_dive_category: null org_triage: null classification: null watchlist_hit: false 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." updates: - at: "2026-08-08T04:47:00Z" run_id: 2026-08-08T0409Z-intel type: update summary: > 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. fields: - actions - affected_products - cves - evidence - regions - sources - tags - techniques - body merged_from: 2026-08-08/zapscape-cve-2026-64561-kvm-shadow-mmu-second-vm-escape migrated_from: null --- 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](https://www.bleepingcomputer.com/news/linux/new-januscape-linux-kernel-flaw-allows-vm-escape-on-intel-amd-devices/)). 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](https://github.com/V4bel/Januscape)). 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](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=81ccda30b4e8); [V4bel, 2026-07-07](https://github.com/V4bel/Januscape)). 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](https://github.com/V4bel/Januscape)). 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](https://www.bleepingcomputer.com/news/linux/new-januscape-linux-kernel-flaw-allows-vm-escape-on-intel-amd-devices/)). Mapped to `T1611 Escape to Host`. **Defender takeaway:** any Swiss/EU public-sector or critical-infrastructure estate running KVM-backed private cloud or renting KVM capacity is in scope — a single hostile tenant (or a tenant whose guest root is compromised) can take down or take over the physical host. Prioritise the host-kernel patch above (guest patching does not help), and until every KVM host is on a fixed train, watch for host kernel-panic/oops events correlated with one tenant's VM as the DoS signature; not-yet-public RCE would surface as unexpected host-level process execution or new host accounts with no corresponding admin action. ## Update — 2026-08-08T04:47:00Z 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](https://github.com/V4bel/Zapscape/blob/main/assets/write-up.md)). The upstream fix, commit `2abd5287f083`, moves the stale-root check after `make_mmu_pages_available()` ([V4bel, 2026-08-06](https://github.com/V4bel/Zapscape/blob/main/assets/write-up.md)). 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](https://ccb.belgium.be/advisories/warning-vm-escape-vulnerabilities-kvm-patch-immediately)). 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](https://github.com/V4bel/Zapscape/blob/main/assets/write-up.md)); 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](https://ccb.belgium.be/advisories/warning-vm-escape-vulnerabilities-kvm-patch-immediately)). 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](https://ccb.belgium.be/advisories/warning-vm-escape-vulnerabilities-kvm-patch-immediately)). The researcher's current public demonstration runs on AMD nested SVM/NPT ([V4bel, 2026-08-06](https://github.com/V4bel/Zapscape/blob/main/assets/write-up.md)). **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.