Januscape (CVE-2026-53359): KVM Host Escape Vulnerability for Proxmox Operators

CVE-2026-53359 — Januscape.

TL;DR

• A KVM hypervisor-level use-after-free in the x86 shadow MMU (code introduced 2010) allows a root-level guest VM to corrupt host kernel memory when nested virtualization is exposed.
• CVE score: CVSS 8.8. Affects both Intel and AMD hosts; no patch level, user privileges, or cloud-provider policy changes required — only guest root + nested virt exposure.
• Patched kernels are available for all Proxmox versions (7/8/9). KernelCare livepatches also exist for PVE 7 and 8.
• The standard (non-nested-virt) Proxmox homelab setup is not affected. The threat surface is the small fraction of operators using "host" CPU passthrough or explicit VMX/SVM flags in their VM configurations.

The Vulnerability

CVE-2026-53359, nicknamed Januscape, is a use-after-free bug in the Linux kernel's KVM x86 shadow MMU subsystem — specifically in kvm_mmu_get_child_sp().

The function validates whether a cached shadow page is still valid for a guest's page table mapping by comparing the Guest Frame Number (GFN). However, it does not compare the shadow page's role (which encodes level, directness, access flags, and translation context).

The consequence: a shadow page with an identical GFN but different role gets incorrectly reused. This leaves a stale reverse-map entry pointing to a shadow page that KVM later frees. When the kernel walks reverse maps — during dirty logging or MMU notifier invalidation — it dereferences the freed page. The result is a use-after-free inside hypervisor memory management code.

Technical root cause details

• Location: arch/x86/kvm/mmu/mmu.c
• Introduced: 2010, missed during kernel review due to lack of KVM shadow MMU fuzzing at the time.
• Fixed upstream: June 16, 2026 via two coupled patches:
  • 81ccda30b4e8 — CVE-2026-53359 (the escape fix)
  • 0cb2af2ea66a — CVE-2026-46113 (companion frame-number check)
  • Both required for a complete fix.
• Coverage: Both Intel VMX/EPT and AMD SVM/NPT — shared KVM/x86 MMU logic.

Impact breakdown

The Linux Security Team's public description frames Januscape as a "potentially serious guest-to-host escape." In practice, two distinct outcomes are documented:

• PoC outcome (public): Guest triggers host kernel panic — reliable DoS of the physical host. Proof-of-concept exists publicly on GitHub (V4bel/Januscape) and works against Linux 6.17 under testing.
• Fully-working exploit (withheld): A complete guest-to-host escape that preserves guest stealth after success has been privately shared with at least one vendor. The full chain has not been publicly released, though the write-up confirms it is in controlled hands.

The 9-Step Attack Chain

1. Vulnerable host boot: Hypervisor boots unpatched (pre-June 16, 2026 kernel) with nested virtualization enabled.
2. Nested VM creation: Attacker with root inside the primary guest creates a second-level VM using KVM ioctls (KVM_CREATE_VM, KVM_SET_CPUID2) and exposes VMX/SVM flags or uses host CPU passthrough.
3. Guest Linux kernel loads: L1 nested guest boots with KVM in its BIOS. Its own KVM stack initializes shadow paging — same code as the parent, identical bug exposed at two levels of the MMU hierarchy simultaneously.
4. Page-table manipulation: Attacker uses KVM_SET_USER_MEMORY_REGION to create a region that maps guest virtual pages into a host-resident GFN but writes it with an intentionally different shadow-page role, forcing KVM's page-table walker down the validation shortcut.
5. Shadow-page cache corruption: Two shadow pages — one real, one crafted — share the same GFN but hold different roles. KVM caches the crafted one as valid for that GFN and binds it to a legitimate rmap entry under its original role; writes land in the wrong place.
6. Use-after-free in the host: When the host's MMU notifier or dirty-flag walker runs later, it walks the rmaps pointing at freed shadow pages. Dereferencing those gives arbitrary kernel read/write from guest context. No privilege escalation step — KVM already trusts the L1 guest to manage its own MMU state.
7. KASLR bypass: The page-walk leak exposes host kernel memory, defeating address-space layout randomization and locating commit_creds()/prepare_kernel_cred(0).
8. Host root escalation: Attacker calls commit_creds(prepare_kernel_cred(0)) from guest context — effectively gaining host-level root.
9. Silence: No guest-level indicators, no hypervisor event log entries (at the level visible to operators), and the guest continues running normally. Only post-incident forensics could show host memory corruption — if it was noticed at all before patch deployment.

What Januscape Is Not

• DirtyFrag (CVE-2026-43284) — local privilege escalation in IPsec/rxrpc modules. Different attack surface, different fix path.
• A Proxmox VE application-layer bug — this is a kernel-level KVM vulnerability. PVE is affected only because it ships with vulnerable kernels.
• A container escape (GhostLock) — CVE-2026-43499 covers unprivileged LXC container escapes and is distinct from Januscape's guest-to-host path.

Proxmox VE Impact Assessment

Affected versions and fixed kernels

All fixed kernels have been promoted from pve-no-subscription (stable) into enterprise repos.

Nested virtualization: the exposure factor

This is the single most important point for operators:

• The kernel module enables nested KVM by default (/sys/module/kvm_intel/parameters/nested shows Y). This is a host-module setting, not a per-VM setting.
• A VM only exercises nested virtualization if:
  • Its CPU is set to "host" model (full passthrough of host CPU features), OR
  • It's explicitly configured with VMX/SVM flags in the Proxmox CPU settings panel.
• The default Proxmox VE CPU model for VMs does not expose virtualization extensions to the guest.

Bottom line: A standard Proxmox install with only trusted VMs and no nested-virt configuration is not exposed to this vector. The attack surface opens when someone explicitly configures "host" CPU passthrough or enables VMX/SVM flags on a VM.

Threat model by operator tier

Mitigation (before patching)

If you cannot reboot immediately:

# Disable nested KVM at the module level
echo 'options kvm-intel nested=N' > /etc/modprobe.d/nested-kvm.conf
echo 'options kvm-amd nested=0' >> /etc/modprobe.d/nested-kvm.conf

# Refresh initramfs so it takes effect on next boot:
update-initramfs -u
# (or: dracut --force on RHEL-based systems)

To close the secondary attack path (/dev/kvm world-accessible):

# Restrict /dev/kvm to kvm group only
echo 'KERNEL=="kvm", GROUP="kvm", MODE="0660"' | tee /etc/udev/rules.d/65-kvm.rules
udevadm control --reload-rules
udevadm trigger /dev/kvm

Patching (permanent fix)

# Update Proxmox VE and reboot into patched kernel:
apt update
apt full-upgrade
reboot

# Verify:
uname -r  # should show the fixed version from the table above

# Check KVM settings post-reboot:
grep nested /sys/module/kvm_intel/parameters/nested
ls -la /dev/kvm

KernelCare livepatches (no reboot)

For Proxmox VE 7 and 8, KernelCare offers no-reboot patches. Verify with:

kcarectl --patch-info | grep -E 'CVE-2026-53359|CVE-2026-46113'

Detection

If the public PoC ran: The host kernel panics. Crash dump analysis shows shadow-MMU corruption — unusual page-walk patterns in kvm_mmu_get_child_sp()'s domain, stale rmap entries pointing at freed pages.

If a stealth exploit was used (full escape withheld):

• No guest-side indicators; the L1 VM continues normally after the escape.
• Host: look for unusual kvm process memory usage, unexpected shadow page allocations under high-affinity CPU cores, and rmap walks on pages that should not exist at those roles.
• KVM_SET_CPUID2 or nested-VM ioctls in strace output of guest userspace processes — especially from unprivileged accounts within the VM.
• For enterprise environments: baseline monitoring for any new VM creation pattern that enables "host" CPU model at runtime (not just config file).

Hardening Recommendations

1. Patch the host kernel immediately. Patched kernels exist for all Proxmox versions. Reboot into them — installing does not take effect until boot.
2. Audit VM CPU configurations. List every VM with --cpu host or explicit VMX/SVM flags. Disable nested-virt flags on any that don't need it (most don't).
3. Disable nested KVM module when unnecessary. Especially critical for multi-tenant environments; the PoC confirmed unpatched hosts with nested virt enabled were exploitable to host panic and likely escape.
4. Restrict /dev/kvm. Mode 0660 owned by kvm:kvm. Prevents unprivileged local users from spawning throwaway VMs for exploitation.
5. Monitor MMU notifier and dirty logging patterns. Anything unusual in shadow page rmap walks at non-standard roles is a strong indicator of exploitation activity.
6. Apply KernelCare livepatches where possible. No-reboot option is valuable for enterprise environments with coordinated migration windows.

Distribution Timeline (Public Disclosure)

• June 16, 2026: Linux Security Team patches upstream (CVE-2026-53359 + CVE-2026-46113).
• July 2, 2026: Proxmox staff confirmed awareness; mitigation thread opened. Fixed test kernels pushed to pve-test.
• ~July 7: Community confirmation from kernel developers that the fix is correct.
• July 8: Public GitHub PoC (V4bel/Januscape) begins circulating; Linux Security Team explicitly notes it works against 6.17 on testing kernels and demonstrates both host panic and controlled escape paths.
• ~July 20–25: Fixed kernels promoted to stable (pve-no-subscription) repos across all PVE versions; enterprise repo promotion follows.
• Journals now open — full public write-ups published. Research is complete and accessible; hardened operators have been operating safely since the patch window closed.

Sources

• Penligent: "CVE-2026-53359 in Proxmox, What Januscape Means for KVM Hosts" — https://www.penligent.ai/hackinglabs/cve-2026-53359-proxmox
• Proxmox Forum: DirtyFrag thread — forum link
• Proxmox Forum: Januscape mitigation thread — forum link
• TuxCare: "Januscape CVE-2026-53359 KVM Guest Escape" — https://tuxcare.com/blog/januscape-exposes-the-kvm-shadow-paging-bug-that-kept-coming-back
• CloudLinux/KernelCare: "Januscape Mitigation and Kernel Update" — https://blog.cloudlinux.com/januscape-cve-2026-53359-mitigation-and-kernel-update-on-cloudlinux
• GitHub: V4bel/Januscape (public PoC) — https://github.com/V4bel/Januscape
• NVD: CVE-2026-53359 — https://nvd.nist.gov/vuln/detail/CVE-2026-53359
• Openwall oss-security: Januscape disclosure — thread link
• Proxmox Security Advisories: PSA-2026-00019-1, PSA-2026-00019-2

This is an evergreen deep-dive. Updated regularly as new research, PoCs, or vendor advisories appear.