A new ARM64 KVM vulnerability let guests read and write host memory, so VPS isolation isn’t absolute. What it means if you rent a VPS, and what doesn’t apply.
Table of Contents
A researcher disclosed a Linux kernel bug this month that lets a virtual machine read and write its host server’s memory, 64 bits at a time, with no hardware trap to stop it. It is the third publicly disclosed KVM guest-to-host escape in roughly two months, and if you rent a VPS, CVE-2026-89775 does not affect standard VPS users. Understanding what triggers the bug matters more than the headline severity score.
CVE-2026-89775 Overview and Standard VPS Impact
KVM is the virtualization technology that turns one physical server into many isolated virtual machines, and it is what most VPS hosting runs on, including ours. CVE-2026-89775 lives in KVM’s ARM64 code and affects a specific feature called nested virtualization, where a guest VM is itself allowed to run virtual machines inside it.
Under that configuration, a flaw in how the kernel manages freed memory means a guest can end up with direct read and write access to memory the host kernel is actively using, without triggering the hardware-level trap that would normally hand control back to the host and stop the operation. Security researchers who reviewed the disclosure describe the worst case as a guest escaping its VM boundary entirely and running code directly on the host.
Vendor CVSS scores range from 7.8 to 9.3 depending on how each distribution’s security team weighed the exploitation conditions; Ubuntu assigned it 9.3 but classified the fix priority as medium, which tells you something about how vendors themselves read the practical risk versus the raw score.
What is the ARM64 Nested Virtualization Vulnerability Scope?
Nested virtualization is off by default on ARM64 systems. A host has to deliberately enable it for a guest to even attempt this attack path. Most commercial VPS hosting, including standard KVM VPS plans, doesn’t hand guests the ability to run their own nested VMs, because it is a specialized feature with performance and isolation tradeoffs that most customers never need. If you are renting a standard VPS to run a website, an application, or a small business workload, nested virtualization almost certainly isn’t part of your plan, and this specific bug doesn’t reach you regardless of what kernel version your host is running underneath.
Where it matters is narrower: providers who specifically market nested virtualization or “VM-in-a-VM” capability, cloud labs and CI/CD platforms that spin up throwaway virtual machines inside customer instances, and ARM64-based cloud infrastructure specifically (the flaw doesn’t affect x86 KVM the same way). As of late September, the bug wasn’t in CISA’s catalog of known exploited vulnerabilities, and researchers estimated the probability of exploitation at under 1%, largely because the attack requires an attacker to already control a guest with nested virtualization exposed, a fairly specific starting position.
What is Hypervisor Shared Hardware Architecture?
It helps to be concrete about what “shared hardware” means, since the phrase gets used loosely. A single physical server, one machine with a fixed amount of CPU, RAM, and storage, gets carved up by the hypervisor into a dozen or more separate VPS instances, each running its own operating system, each unaware of the others by design.
Your VPS and a stranger’s VPS can sit on the exact same physical box without either of you ever knowing it, and the entire premise of that arrangement being safe rests on the hypervisor enforcing a hard wall between guests. That is precisely the wall a guest-to-host escape bypasses.
These bugs get disproportionate security research attention relative to a flaw in a single web application because a successful VPS-hosting hypervisor escape doesn’t just compromise one customer; it potentially exposes every other tenant on the same physical hardware, which is a fundamentally different blast radius than almost any other kind of server vulnerability.
Recent KVM Vulnerability Timeline
In late July, researchers disclosed Januscape (CVE-2026-53359), a use-after-free bug that had sat unnoticed in KVM’s x86 code since 2010, roughly 16 years, and worked on both Intel and AMD hardware. In August, Zapscape (CVE-2026-64561) surfaced, a related x86 flaw letting an attacker with root inside a guest VM escape KVM isolation when nested virtualization was exposed to untrusted tenants, with similar mechanics and the same underlying category of bug. Now, in September, CVE-2026-89775 brings the same class of flaw to ARM64. Three guest-to-host KVM escapes, three different code paths, disclosed within about eight weeks of each other.
That is not evidence KVM itself is newly unsafe. If anything it is the opposite: increased security research attention on hypervisor isolation, likely driven by how much more infrastructure now runs on shared virtualized hardware than a decade ago, is finding bugs that had been sitting in the code for years without anyone looking hard enough to catch them. But if you are choosing or evaluating VPS hosting, evaluating your provider’s patch cadence is critical rather than accepting generic assurances that your VPS is isolated.
Questions to Ask Your Host
The useful question is narrower: does your VPS plan expose nested virtualization to guests by default, and if so, can it be disabled for accounts that don’t need it. A provider that can answer that specifically, rather than falling back to generic enterprise-grade security language, is tracking which of its own configurations sit inside the blast radius of bugs like this one.
It is also worth asking how quickly host-level kernel patches get applied across the fleet when a CVE like this lands, since the fix here exists in mainline Linux (6.18.51, 7.2.5, and 7.3-rc1) but still has to reach every distribution and every host running it, a process that took weeks for the earlier two KVM escapes to fully roll out across major distributions.
Administrators should examine patch windows in practice rather than relying on written policies. A host-level kernel update on shared infrastructure isn’t as simple as pushing an update to a single machine; it typically means scheduling a maintenance window, migrating running guests off a physical host or briefly interrupting them, patching, and validating before moving on to the next box in the fleet. A provider that can describe that process concretely, rather than offering a vague statement about patching regularly, is signaling that host-level patching is an operational discipline rather than an afterthought handled reactively once a CVE makes headlines.
KVM Isolation Model Comparison
Users shouldn’t avoid KVM-based VPS hosting specifically based on these disclosures. KVM remains one of the most widely audited hypervisor technologies precisely because it is used at this scale, and that scrutiny is what surfaced all three of these bugs before they were found through active exploitation rather than after.
Container-based virtualization, which some budget hosts use instead of true hypervisor isolation to pack more customers onto the same hardware, generally offers weaker tenant separation than KVM does even with an unpatched CVE in the mix, because containers share a kernel by design rather than as a bug.
We go into the practical difference in our guide to KVM VPS hosting, and the isolation question is also part of what separates managed from unmanaged VPS plans, since a managed provider is responsible for applying host-level kernel patches like this one before a guest ever has the chance to test them.
If you manage your own VPS and want to check your exposure directly, cat /proc/cpuinfo and your hypervisor’s guest configuration will tell you whether nested virtualization is active on your instance. For nearly everyone running a standard website or application workload, the honest answer will be that it isn’t, and this particular bug simply doesn’t apply. The pattern behind it, three isolation-breaking bugs surfacing in eight weeks, is still worth remembering the next time isolation is the main thing you’re paying a host for.
Key Takeaways on VPS Isolation
- VPS isolation is strong but not absolute; a hypervisor flaw can weaken the boundary between virtual machines.
- Check whether your provider runs the affected configuration before assuming your VPS isolation is at risk.
- Keep your own server patched and watch your provider’s advisories, because VPS isolation is only one layer of defense.
- Ask your provider how it patches the hypervisor, because vps isolation depends on it.
- Do not store secrets on a server you do not trust, whatever the vps isolation claims.
- Treat vps isolation as a layer of defense, not a guarantee.
Further reading: Linux kernel documentation: KVM.