Januscape (CVE-2026-53359): How we patched all our Proxmox clusters without any downtime. A workshop report.

A compromised virtual machine with the right conditions in place, and in the worst-case scenario, an attacker has code execution within the kernel context of the host, on which dozens of other VMs are still running. This is not a hypothetical scenario, but precisely the threat landscape that the ‘Januscape’ vulnerability in KVM/x86 brought to life in July 2026.

A recent case from Claranet’s own experience illustrates just how critical such a vulnerability is for any virtualisation operator: within a very short space of time, all Proxmox nodes had to be secured and patched – without any downtime for the running VMs and without customers having to take any action themselves.

The background: A vulnerability breaches the isolation between guest and host

The security vulnerability known as ‘Januscape’ (CVE-2026-53359) affects KVM (Kernel-based Virtual Machine) on x86 architecture and enables a so-called guest-to-host escape: An attacker with sufficient privileges within a guest VM can exploit the vulnerability to escape from it and gain control of the underlying host system.

The cause is a use-after-free vulnerability in the Shadow MMU emulation of KVM/x86. The flaw remained undetected in the kernel for around 16 years and affects both Intel and AMD processors equally. ARM64 hosts are not affected by Januscape.

Important for context: the fix had long been available at the time of the public announcement. The patch (commit 81ccda30b4e8) was merged into the mainline kernel on 19 June 2026; the patched stable kernels were released on 4 July 2026, and it was not until 6 July, following the lifting of the embargo, that the public disclosure took place via the oss-security mailing list. What was missing in our situation were ready-made distribution packages for Proxmox.

This left us with three problems:

• A ready-made, patched kernel package from Proxmox was not yet available at the time of the report, even though the upstream fix already existed.
• A kernel update on Proxmox hosts requires a reboot, which had to be carried out without causing any downtime for the running VMs.
• As a managed service provider with a large number of Proxmox hosts for various customers, every minute counted in this situation.

What is the technical background to this? Shadow MMU and use-after-free

The Shadow MMU emulates a virtual machine’s memory management in software, rather than leaving it to the CPU. Modern processors actually handle this translation in hardware (Intel EPT, AMD NPT). However, as soon as a guest itself acts as a hypervisor, KVM must once again shadow the nested page tables managed by the guest in software. It was precisely this code path that Januscape exploited, which is why the vulnerability also affected hosts on which EPT or NPT are normally active.

At its core lies the incorrect reuse of a shadow page: until now, KVM had essentially identified a shadow page via the Guest Frame Number (GFN), but not entirely via its role. This meant that a shadow page with a matching GFN but a different role could be reused, even though the two objects are not interchangeable. Consequently, an outdated reverse-mapping association persisted, the associated `kvm_mmu_page` structure was freed, and subsequent memory operations accessed memory that had already been freed. It is precisely this access to freed memory that constitutes the use-after-free at the heart of CVE-2026-53359. Januscape is not the first discovery in this part of the code: a related bug had already been fixed in May 2026 as CVE-2026-46113 (commit 0cb2af2ea66a). However, that fix only checked whether KVM had found the correct GFN. Januscape demonstrated that the role of the shadow page must also be checked. Anyone who applied the patch in May and considers the issue resolved remains vulnerable. Both commits are interdependent.

The vulnerability was discovered by security researcher Hyunwoo Kim (@v4bel), who reported it via Google’s kvmCTF programme and published a proof-of-concept. It is important to note that the publicly available PoC only leads to a host panic (Denial of Service). According to the researcher, he has demonstrated a full escape exploit in a controlled environment but has not published it. The worst-case scenario described at the outset has therefore been technically validated, but is not part of the public PoC.

Why Januscape is particularly critical as a VM escape

Breach of kernel isolation: Guest-to-host escapes are among the most serious classes of vulnerabilities in virtualised environments.

Exploitable from within the guest VM without direct host access: An attacker does not require physical or administrative access to the host. However, this is not a vulnerability accessible via the network, but rather an escalation path initiated from within a guest VM. A prerequisite is privileged code execution within the guest. The published PoC utilises root privileges in the guest and the loading of a custom kernel module; this is the demonstrated method, but not necessarily the minimum requirement for the attack.

Nested virtualisation is effectively the most important prerequisite for the guest attack path: the vulnerable code path is reached whenever KVM emulates page tables in software. In practice, exposed nested virtualisation is almost always to blame; however, the Shadow MMU is also used when hardware support (Intel EPT or AMD NPT) is unavailable or has been deliberately disabled. Environments with nested virtualisation enabled are therefore particularly at risk.

Distribution packages initially unavailable: When the vulnerability was made public, although the upstream fix was already available, ready-made patched packages for the distribution in use were not yet available. Until these became available, workarounds were the only option.

Checking for vulnerability: Which Proxmox hosts are at risk?

Based on the technical requirements, there are three key questions that every operator of a KVM or Proxmox cluster should answer:

• Is nested virtualisation enabled, and does the host otherwise use hardware paging throughout? Exposed nested virtualisation features are, in practice, the most significant route into the vulnerable Shadow MMU path. However, a host without nesting is only safe if EPT or NPT are actually enabled.
• How trustworthy are the guests? The attacker requires privileged code execution within the guest; the published PoC utilises root privileges and a custom kernel module for this purpose. Environments in which customers or third parties run their own VMs with root privileges are therefore significantly more exposed than environments with only the organisation’s own, managed guests.
• Is a patched kernel running? The upstream fix was available at the time of disclosure; the distribution packages followed some time later. What matters is the kernel version actually running on the host, not the state of the repository.

These three points can be checked on any host in a matter of seconds.

Determine the current kernel version:

uname -r
Check the nested virtualisation status (depending on the CPU manufacturer):
cat /sys/module/kvm_intel/parameters/nested
cat /sys/module/kvm_amd/parameters/nested

A ‘Y’ or ‘1’ means active; an ‘N’ or ‘0’ means inactive. If the file does not exist, the corresponding module is not loaded.

Check whether both fixes are included in the installed distribution kernel:

apt changelog "linux-image-$(uname -r)" | grep -iE 'CVE-2026-53359|CVE-2026-46113'

The actual kernel version currently running is always the decisive factor, not the status of the repository: an installed package only takes effect after a reboot. Upstream, the fixes are included in the stable branches 5.10.260, 5.15.211, 6.1.177, 6.6.144, 6.12.95, 6.18.38 and 7.1.3, as well as from 7.2-rc1 onwards (in each case, the first version to include the backport; later releases in the same series also contain it); for distribution kernels, the backport should be verified in the changelog rather than estimated based on the version number.

Initial response: assessment and immediate measures

As soon as the report came in via our internal channels, the incident response process was initiated. The first questions:

• Which of our Proxmox hosts use nested virtualisation and are therefore exposed to the guest attack vector at all?
• What workaround can be implemented immediately and without risk to running VMs?

As no patched distribution packages were available at the time of the report, the team implemented several measures with immediate effect: disabling nested virtualisation on all hosts where it was not strictly necessary, restricting the execution of untrusted guest VMs on particularly vulnerable hosts, and stepping up monitoring of all systems for suspicious activity.

To this end, all Proxmox nodes were automatically inventoried and checked, rather than proceeding manually host by host – a crucial time-saving advantage.

Special case: Nutanix AHV – checked and classified

As Nutanix AHV is also based on KVM/QEMU, the question arose as to whether this platform was also affected. The assessment revealed that nested virtualisation is not enabled by default on AHV. It must be explicitly enabled for each VM (via `cpu_passthrough`) and precludes live migration for the affected VM, which is why it is rarely used in regular production environments anyway. The advisory nutanix-sa-0051 lists the following configurations as exposing vulnerabilities: hardware virtualisation, CPU passthrough, Credential Guard or Virtualisation-based Security, WSL2 and equivalent functions that expose the VT-x and AMD-V extensions to the guest. An assessment should therefore not rely on a single feature, but should cover all the cases mentioned in this list. The status cannot be checked in Prism, but only at the aCLI or API level: `acli vm.get "*"` outputs the full configuration of all VMs, with the flag appearing only on the affected machines; for a repeatable inventory, the VM API is the cleaner approach. It is important to interpret the result correctly: if no matches are found, the known exposure path is not in use at the time of the check. This is not a cause for reassurance, however, as Nutanix itself does not specify a supported workaround for AHV, and an empty result may also be due to syntax, AOS version or permissions.

In our AHV environment, Nested Virtualisation was therefore not enabled, meaning that the known guest attack path from Januscape was not exposed there.

To be on the safe side, we did not rely solely on this assessment, but also ran the publicly available PoC exploit in a controlled test environment. The result confirmed the analysis: without nested virtualisation enabled, the exploit did not work on AHV. This meant that the assessment was not only theoretically sound but also practically validated. In the interests of honesty, two caveats should be noted: the public PoC only covers the DoS attack vector; therefore, a crash that does not occur is not proof of invulnerability. Furthermore, ‘not exposed’ does not mean ‘unpatched’: in advisory nutanix-sa-0051 dated 10 July 2026, Nutanix classifies AHV as affected, assigns the vulnerability a CVSS score of 7.8 and explicitly states that there is no supported workaround. For standard VMs without exposed virtualisation extensions, Nutanix does not expect any exposure; the only effective remedy for affected VMs is to upgrade to the release containing the fix, which had yet to be announced at the time of writing.

Patching Proxmox clusters without downtime: live migration and HA design

How was the security incident resolved? Once patched kernel packages became available, Claranet patched all Proxmox clusters node by node:

• VMs were automatically migrated to other nodes in the cluster before each reboot.
• The cleared node was updated and restarted.
• It was then reintegrated into the cluster.

Thanks to the existing HA design, there was no downtime either during the VM migrations or the node restarts. Throughout the entire process, there were no unplanned outages and no security incidents.

This is the practical difference between a cluster in which live migration and high availability are in place, and an environment in which a kernel update requires a scheduled maintenance window.

What this incident reveals about patch management at a managed service provider

There are two questions IT managers regularly ask when it comes to operating virtualised environments: What downtime can be expected? And are there qualified service providers who can handle this? This incident answers both questions using a real-life example.

• Round-the-clock responsiveness: The report was dealt with immediately, an incident process was initiated and initial emergency measures were put in place even before patched packages were available for our environment.
• Centralised inventory and automation: Rather than checking each host individually, centralised management enabled rapid, consistent and documented implementation across the entire fleet.
• Risk-based prioritisation rather than a knee-jerk reaction: By specifically assessing which hosts were actually exposed due to nested virtualisation, the team was able to deploy resources where they would have the greatest impact.
• Customers did not need to take any action: migration , patch roll-out and verification ran entirely in the background. This was the result of a well-prepared, tool-supported operational organisation.

Outlook: Virtualisation vulnerabilities remain a growing risk

Januscape is the latest in a series of critical vulnerabilities demonstrating that even the fundamental isolation mechanisms of virtualisation are not impregnable. Those without automated inventory management, live migration capabilities and pre-planned patch pipelines will inevitably have to react rather than act proactively in the event of a crisis.

This applies particularly to organisations currently switching from VMware to Proxmox or Nutanix. Migrating a virtualisation platform also transfers responsibility for its patching cycles.

Conclusion

‘Januscape’ poses a serious threat to any environment relying on KVM/x86 with exposed nested virtualisation. For our Proxmox customers, the matter is resolved: we assessed the vulnerability at an early stage, took immediate action and patched all nodes in a coordinated manner without any action required from the customer. For Nutanix AHV, the issue remains unresolved until Nutanix has released the fix. Anyone running AHV should continue to monitor advisory nutanix-sa-0051 and keep an eye on the affected VMs until then.

Running virtualisation as a managed service

Januscape has demonstrated what matters most in an emergency: an up-to-date inventory, prepared live migration and a team that responds round the clock. If you do not wish to monitor and patch your Proxmox, KVM or Nutanix environment yourself 24/7, we would be happy to discuss your requirements.

Request a consultation

FAQ on Januscape, KVM, Proxmox and Nutanix AHV

What is Januscape (CVE-2026-53359)?

Januscape is a use-after-free vulnerability in the Shadow MMU emulation of KVM/x86. It enables a guest-to-host escape, i.e. an escape from a virtual machine to the host system. Both Intel and AMD processors are affected; ARM64 hosts are not.

Can Januscape be exploited over the network?

No. This is not a vulnerability that can be exploited remotely over the network. The attacker must be able to execute code within a guest VM with privileged rights – the published PoC uses root access in the guest and a custom kernel module for this purpose – in order to initiate the escalation path to the host.

Who is particularly affected by this vulnerability?

Operators of KVM/x86 hosts with nested virtualisation enabled, as well as multi-tenant cloud and hosting environments where multiple customer VMs share the same host. Also relevant are systems on which /dev/kvm is accessible to all local users – this is common in the RHEL family. In such cases, the same flaw can be exploited as a local privilege escalation to root.

Is my Proxmox cluster affected?

Three factors are crucial: the actual kernel version running on the host, whether nested virtualisation is enabled, and the trust level of the guests. Environments in which third parties run their own VMs with root privileges are significantly more vulnerable.

Is Nutanix AHV from Januscape affected?

AHV is based on KVM/QEMU; however, nested virtualisation is not enabled by default and must be explicitly enabled on a per-VM basis. This means that the guest attack vector is not exposed in standard configurations. In our AHV environment, we have additionally verified this by running the public PoC in a controlled test environment. However, the absence of exposure is no substitute for a patch: Nutanix classifies AHV as affected in advisory nutanix-sa-0051 and does not provide a supported workaround; the AHV fix had been announced at the time of going to press but had not yet been released. It should also be noted that it is not only cpu_passthrough that is vulnerable, but also Credential Guard, VBS or WSL2 within a guest VM.

What is the quickest workaround against Januscape?

Until patched packages have been installed, disabling nested virtualisation and restricting untrusted guest VMs on affected hosts significantly reduces the risk. On systems that do not run any VMs at all, the KVM modules can also be unloaded and blocked. Hosts that absolutely require nested virtualisation cannot be secured through configuration alone; in such cases, only the patch will help.

Does the workaround replace patching?

No. The workaround reduces the risk immediately, but does not replace a kernel fix. As soon as patched packages are available, a scheduled update window should follow. Both relevant fixes (CVE-2026-53359 and CVE-2026-46113) must be checked.

Can a Proxmox cluster be patched without downtime?

Yes, provided that live migration and a high-availability (HA) design are in place. The VMs are migrated to other nodes before the reboot; the freed-up node is updated and then reintegrated into the cluster. In our case, there was no downtime during either the migrations or the node reboots.