Most cloud and VPS hosting in Europe, and a large share of self-hosted infrastructure, runs on KVM, the Linux kernel’s built-in hypervisor. It underpins offerings from Hetzner, OVHcloud, Scaleway, IONOS, and countless smaller providers, along with any organisation running its own Proxmox or OpenStack cluster. The entire security model of that shared infrastructure rests on one guarantee: a guest virtual machine cannot reach the host, or the other tenants sitting next to it on the same physical box. Januscape, tracked as CVE-2026-53359, breaks that guarantee, and it has apparently been sitting in the kernel for around 16 years.
A shadow MMU bug that spans two CPU vendors
Januscape is a use-after-free in KVM’s shadow MMU, the code path both Intel and AMD platforms share for managing how guest memory addresses map onto physical host memory when nested virtualisation is in play. Security researcher Hyunwoo Kim reported it as, to public knowledge, the first guest-to-host escape triggerable on both Intel and AMD x86 systems from the same underlying flaw. The publicly released proof of concept panics the host, a denial of service that takes down every other tenant on the machine along with the attacker’s own guest. Kim states that a separate, unreleased exploit turns the same bug into full guest-to-host code execution, and submitted the finding to Google’s kvmCTF programme, which pays up to 250,000 dollars for a working guest-to-host escape.
Two CVEs, not one, and both need fixing
The detail that trips up a lot of patch tracking is that Januscape does not close with a single fix. CVE-2026-53359 needs a second, earlier fix, CVE-2026-46113, to fully eliminate the attack path. Patching only the headline CVE leaves the underlying condition exploitable. Fixed stable kernels shipped on July 4, 2026: 7.1.3, 6.18.38, 6.12.95, 6.6.144, 6.1.177, 5.15.211, and 5.10.260. If your distribution backports kernel security fixes rather than tracking upstream stable releases directly, confirm with your vendor that both commits are included, not just the one carrying the CVE that made the headlines.
What to do if you cannot patch today
The condition requires nested virtualisation to be enabled on the host, meaning guests are themselves allowed to run virtual machines. If an immediate kernel update is not possible, disabling nested virtualisation with kvm_intel.nested=0 or kvm_amd.nested=0 removes the attack path for untrusted guests, at the cost of breaking any workload inside your environment that legitimately depends on nested VMs.
For hosting providers and any organisation running its own KVM infrastructure, the practical checklist is short: confirm your host kernels include both fixes, check whether any customer-facing or internal workload requires nested virtualisation and whether that workload can be trusted, and treat any multi-tenant KVM host that has not applied the July 4 fixes as running with a known, public guest-to-host escape path against it. A denial-of-service proof of concept being public means opportunistic disruption is already possible even before anyone reproduces the full code execution chain.
If your organisation runs KVM-based virtualisation, whether through a European cloud provider or on your own bare metal, and you need help confirming your exposure to Januscape or hardening your hypervisor patch process more broadly, contact Excello Digital. We help European infrastructure teams turn kernel-level vulnerabilities into a clear, verified patch status instead of an open question.