A public exploit for CVE-2026-53359, nicknamed Januscape, can reportedly crash a Linux KVM host within minutes, taking down every virtual machine running on it. The researcher who discovered the vulnerability says a separate, unreleased exploit achieves full guest-to-host code execution. That distinction matters: the public demonstration establishes a host-crash risk; the claim of full host compromise comes from the researcher.
As of July 14, 2026, patches and a public proof of concept are available. Reporting on Januscape describes a use-after-free in KVM's shadow memory management unit, or shadow MMU, dating to August 2010. The exploit is reported to work on both Intel and AMD x86 hardware.
For hosting operators, the main configuration to examine is nested virtualization: allowing a guest VM to run another hypervisor. The reported guest attack requires root inside the VM and access to nested virtualization. Giving tenants root is normal on many hosting platforms, so the second condition is often the more useful place to start checking exposure.
How the shadow MMU becomes involved
Modern x86 processors provide hardware support for translating guest memory addresses. Intel calls it Extended Page Tables (EPT); AMD calls it Nested Page Tables (NPT). The CPU handles the two layers of translation, from guest virtual addresses to guest physical addresses, then from guest physical addresses to host physical addresses. KVM uses this hardware-assisted path by default on virtually every server built in the last decade.
The shadow MMU is the older software-managed alternative. KVM maintains shadow page tables that map guest virtual addresses directly to host physical addresses. Keeping those mappings correct requires tracking guest page-table changes, intercepting write faults, rebuilding mappings, and maintaining reverse maps that connect guest frames to shadow mappings.
Shadow paging remains relevant when hardware paging is unavailable and in nested virtualization configurations. It is a complicated fallback path, even though ordinary workloads on EPT/NPT-capable hosts largely avoid it. The affected code dates to Linux 2.6.36 in 2010.
A cached page was reused with the wrong role
The vulnerability is in arch/x86/kvm/mmu/mmu.c, in the function kvm_mmu_get_child_sp(). When KVM looks for an existing shadow page to reuse, it needs to match both the guest frame number (GFN) and the page's role. The role is a bitfield describing attributes such as the page level and whether the mapping is direct or indirect.
Under a particular sequence of guest page-table changes, the full role comparison was effectively skipped. The published explanation of the exploit sequence describes these steps:
- The guest creates a 2 MB mapping, and KVM builds a direct shadow page for it.
- The guest changes that mapping to point through a 4 KB page table.
- The next page-table walk needs a non-direct shadow page at the same guest frame. Instead,
kvm_mmu_get_child_sp()finds the old direct page by frame number and reuses it without the full role check. - A stale reverse-map entry remains associated with the old page's frame number.
- KVM eventually frees the shadow page, leaving the stale entry pointing to freed memory.
- During a later operation, such as dirty logging or MMU-notifier invalidation, KVM follows the reverse map and accesses that freed memory.
This is a use-after-free: code accesses memory after the object occupying it has been released. Here, the immediate demonstrated result is a host kernel panic.
The fix, commit 81ccda30b4e8, adds a check that role.word matches alongside the frame number before a cached shadow page can be reused.
A companion vulnerability, CVE-2026-46113, addresses a different stale-shadow-page condition in the same code. Its fix is commit 0cb2af2ea66a. Both fixes are needed. An update covering only CVE-2026-46113, which some distributions shipped in May, does not resolve Januscape.
What the researcher has demonstrated
Security researcher Hyunwoo Kim, @v4bel on Hacker News, submitted the vulnerability to Google's kvmCTF program. The controlled vulnerability reward program offers up to $250,000 for full guest-to-host escapes.
The NVD published the CVE on July 4, 2026. The embargo ended on July 6, and the public proof of concept appeared on GitHub that day. It reliably panics the host kernel within minutes, according to the reporting.
Kim describes Januscape as the first publicly confirmed guest-to-host exploit triggerable on both Intel and AMD without vendor-specific assumptions. Kim also says the unreleased variant achieves full host code execution. A host crash alone is a serious multi-tenant availability problem, since every co-tenant VM on that machine goes down with it.
This is Kim's second disclosed shadow MMU use-after-free in two months, following CVE-2026-46113 in May. The two discoveries support closer examination of this code, though they do not establish how many other vulnerabilities remain.
Which configurations need attention
The reported guest attack has two prerequisites: root privileges inside a guest VM and nested virtualization enabled or exposed to that guest. On a platform that gives tenants root or sudo access, the first requirement is already met when a tenant rents an instance.
The reported exposure analysis treats ordinary, non-nested VMs on EPT/NPT-capable hosts as outside the guest attack path because they bypass shadow paging. Nested virtualization can bring the affected shadow MMU code into use. Configurations to review include:
- Nested KVM used by CI pipelines to run VMs inside test VMs.
- Development environments where tenants run their own hypervisors.
- Kubernetes nodes running in VMs with nested virtualization enabled for VM-based container runtimes.
- Proxmox VE clusters where nested virtualization has been enabled for Windows guests, including configurations described as needing Hyper-V enlightenments.
- Lab or staging hosts where nested virtualization was enabled temporarily and left on.
There is also a reported local-user exposure on RHEL-family systems. The advisory coverage describes /dev/kvm as shipping with world-readable and world-writable permissions, mode 0666. Where that configuration is present, an unprivileged user with a shell on the host can reportedly trigger Januscape through access to KVM, without first obtaining root in an existing tenant VM. Shared development hosts and multi-user build machines therefore need a permissions check as well as a review of tenant VM settings.
Patched kernels and distribution updates
The upstream fix reached stable kernels on July 4, 2026. The reported patched versions are:
7.1.36.18.386.12.956.6.1446.1.1775.15.2115.10.260
Distribution kernel version numbers are less straightforward. Enterprise distributions backport KVM changes into older kernel baselines. RHEL 9 and AlmaLinux 9 use a 5.14-based kernel, but their KVM code includes newer upstream changes. An older baseline alone does not establish that a host is unaffected.
Check for a distribution KVM update explicitly covering CVE-2026-53359, and verify that it includes the fix from commit 81ccda30b4e8. Distribution errata are a better guide than uname -r alone. The companion fix for CVE-2026-46113 also needs to be present.
Mitigations before patching
The available mitigation depends on whether the host needs KVM and whether its guests need nested virtualization.
- Hosts that run no VMs: Unload the KVM modules and block their loading. Add
install kvm_intel /bin/falseandinstall kvm_amd /bin/falseto a configuration file under/etc/modprobe.d/. - Hosts that need VMs but not nested virtualization: Disable nesting explicitly with
options kvm_intel nested=0on Intel oroptions kvm_amd nested=0on AMD. Reload the relevant module or reboot for the setting to take effect. - RHEL/AlmaLinux hosts that need nesting and cannot patch immediately: Restrict
/dev/kvmto mode 0660 with group kvm. This restricts the reported local-user route to accounts with the necessary access. It does not close the guest-root attack path.
Live patches covering both CVE-2026-53359 and CVE-2026-46113 are reported as available through KernelCare. Operators using another live-patching service need to confirm coverage for both vulnerabilities rather than assume that any KVM live patch is sufficient. Live patching can avoid a reboot where the service supports the fixes and the running kernel.
Januscape illustrates a specific maintenance problem. EPT and NPT began making shadow paging a fallback around 2007-2008, but the software implementation remained and continued to evolve. Nested virtualization gives that older path a role in current CI, sandboxing, and development workloads. Reduced use by ordinary VMs does not make the code safe to leave unaudited.
Systematic audits of these fallback kernel paths are justified when newer deployment patterns make them reachable again. Affected operators need to establish whether nesting is exposed, check local access to /dev/kvm, and ensure the running kernel has both fixes.
