Januscape (CVE-2026-53359)

Januscape is a vulnerability in KVM/x86 — the virtualisation subsystem built into the Linux kernel, and the technology that most VPS and cloud providers use to slice one physical server into many customers' virtual machines. It is tracked as CVE-2026-53359, and it is unusual in having three distinct impact modes rather than one.

• →Guest-to-host escape (most serious): an attacker who can start a virtual machine can break out of it and run commands as root on the host — the physical server underneath every VM on that hardware.
• →Host-crash denial of service: from inside a guest, the flaw can be used to crash the host kernel outright — taking down every other tenant's VM on the same machine in one stroke.
• →Local root with no VM involved: on any host where the KVM modules are loaded and /dev/kvm is world-accessible at its default 0666 permissions, an unprivileged local user can trigger the bug to gain root directly.

The first mode is the one that breaks the mental model most people carry about virtualised hosting. The entire premise of a VPS is that the walls between virtual machines hold: your neighbour's problems are your neighbour's problems. Januscape is a hole in that wall — and it opens from the neighbour's side.

The flaw was introduced into the kernel in 2010 and fixed upstream on 16 June 2026. That means nearly every Linux kernel shipped in the last 16 years carries it. There is no "old distros only" caveat here, and no comfort in running a recent release: an up-to-the-minute kernel from early June 2026 is just as affected as one from a decade ago. Until a machine has taken a kernel built after the fix, it is vulnerable.

Sixteen years is also long enough for KVM to have become the default substrate of the hosting industry. The budget VPS, the mid-range cloud instance, the hyperscaler virtual machine — under a very large share of them sits a Linux host kernel running KVM, and until last month, essentially all of those host kernels carried Januscape. This is not an exotic edge-case bug in software few people run. It is a flaw in the foundation most of the internet's rented computing stands on.

The fixes are now shipping. Patched kernels for AlmaLinux 9 and 10 reached production repositories on 6 July 2026 — in the same release as the fixes for Bad Epoll (CVE-2026-46242) — and CloudLinux has published a mitigation and kernel update. Alongside GhostLock (CVE-2026-43499), that makes three separate Linux root flaws patched in the same fortnight. The patches exist; the open question, for any given server, is whether they have been applied.

A VPS is a virtual machine on a physical server you share with other customers. You never see them; you don't choose them; you have no idea what they run or how carefully they run it. That's normally fine, because the hypervisor keeps each tenant sealed inside their own guest. Januscape breaks the seal.

Concretely: a malicious customer — or an ordinary customer whose VM has been compromised — can use Januscape to escape their guest and gain root on the host. Root on the host means root over everything on that hardware, including your virtual machine. Your store's disk. Your database, with every customer record and order in it. Your memory, including secrets and session data. Your traffic. All of it readable and writable by someone who was never supposed to be able to see that your VM even exists.

What makes this uncomfortable to write, and worth reading twice, is that none of it involves any failure on your part. Your Magento patching can be immaculate, your admin panel locked down, your extensions audited — and your store is still exposed, because the attack happens a layer below anything you control. You did nothing wrong. You were simply standing next to the wrong neighbour.

And even where an attacker can't or doesn't complete the full escape, the second impact mode still applies: a guest on your host can crash the host kernel, and your store goes down — mid-trading, mid-checkout — because of someone else's virtual machine. Denial of service by association.

The third impact mode deserves its own section, because it catches servers whose owners reasonably believed virtualisation bugs didn't apply to them. On many Linux systems, the KVM kernel modules load automatically when the CPU supports virtualisation — whether or not anything on the machine ever starts a VM. And the /dev/kvm device node ships world-accessible at 0666 permissions by default.

On any host in that state, Januscape stops being a virtualisation story at all. An unprivileged local user — a webshell dropped through a vulnerable Magento extension, a compromised deploy account, any low-privilege foothold — can open /dev/kvm and trigger the flaw to gain root, no virtual machine required. "We don't run VMs" is not the same as "KVM isn't loaded", and it's the second one that determines exposure. It is worth checking rather than assuming.

On a server you control, SSH in and run:

uname -r

Compare the kernel version against your distribution's advisory for CVE-2026-53359:

• AlmaLinux 9 and 10: patched kernels reached production repositories on 6 July 2026, in the same release as the Bad Epoll fixes
• CloudLinux: a mitigation and kernel update have been published — apply both per the CloudLinux advisory
• Other distributions: check your vendor's security tracker for CVE-2026-53359; the upstream kernel fix landed on 16 June 2026

If your kernel predates your distribution's fixed version, update via your package manager and reboot.

Kernel patches are applied as standard across EveryHost's managed infrastructure — that includes the fixes for CVE-2026-53359, alongside the Bad Epoll and GhostLock fixes shipped in the same window. Patch cadence is part of the managed service, not an optional extra, and you can read how we approach platform-level threats in our Magento Security Centre.

There is also an architectural point worth being precise about. EveryHost's Magento platform runs on single-tenant dedicated servers: one customer per physical machine, no co-tenant virtual machines. The headline Januscape scenario — a stranger's guest VM escaping onto the hardware your store runs on — has no surface to work with on that architecture, because there are no co-tenant guests to escape from.

We want to be careful with that claim. It is not invulnerability — no honest host claims that, and we still patch every kernel, everywhere, including for the /dev/kvm local path. It is a statement about exposure: architecture determines which classes of attack can reach you at all, and single-tenancy removes the neighbour-VM class entirely rather than defending against it one CVE at a time.

Januscape is one CVE, and it will be patched everywhere eventually. But it is also a clean illustration of a structural trade-off that Magento store owners rarely get to see so plainly. On multi-tenant virtualised infrastructure — whether a budget VPS or big-brand cloud — part of your security posture is, permanently, the behaviour of strangers on your hardware and the patch discipline of a hypervisor layer you cannot inspect. Most of the time that trade is invisible. Roughly once a decade, a bug like this makes it visible.

We've written up the full argument — costs, performance, and security — in our comparison of Magento cloud hosting against single-tenant alternatives. The short version as it applies here: on dedicated Magento servers, the machine is yours alone. There is no neighbour to escape from, no co-tenant to crash your host, and the blast radius of any kernel-level event is bounded to one customer. A kernel CVE on a dedicated server is a patching task; the same CVE on shared virtualised infrastructure is a patching task plus an exposure to everyone else on the box.

That doesn't make virtualisation wrong — it makes it a choice, with a security dimension that belongs in the decision alongside price and flexibility. For a revenue-critical Magento store, it deserves to be weighed deliberately rather than inherited by default.