No. Nested virtualization is disabled on our KVM vServers. AMD-V and Intel VT-x are not available inside the VM, so Proxmox, Hyper-V, hardware-accelerated VirtualBox or your own KVM guests will not run there. And to be honest: after everything that came to light in 2026, we do not expect to ever enable this feature on shared hosts. If you want to run your own VMs, a dedicated server with virtualization is the right choice.
What do I need virtualization for?
You need virtualization if you want to run additional, fully independent operating systems on your server. Typical tools are Proxmox VE, Hyper-V, VMware ESXi or KVM with libvirt. On a vServer this would be a second layer of virtualization, which is exactly what nested virtualization means: our host runs your VM, and your VM runs its own VMs.
Why is nested virtualization disabled?
The main reason is security. Many customer VMs run side by side on one host. The most important job of the hypervisor is to keep these VMs cleanly separated from each other and from the host. This year, that boundary was broken several times, and every time through nested virtualization.
The vulnerabilities of 2026
- Januscape (CVE-2026-53359), disclosed in July 2026, CVSS 8.8: a use-after-free in the shadow MMU of KVM on x86, affecting both Intel and AMD. The bug sat in the Linux kernel for about 16 years. A guest with root privileges can crash the host, taking down every other VM on it. According to the researchers, code execution on the host is possible as well. A complete fix also requires the patch for CVE-2026-46113, which affects the same code path.
- Zapscape (CVE-2026-64561), disclosed in August 2026: again the shadow MMU of KVM on x86, again a use-after-free. This time there is a public proof of concept that demonstrates a full escape from the VM to root on the host, shown on AMD. The affected code dates back to 2020.
Both vulnerabilities share the same precondition: the host has to offer nested virtualization to the guest. Only then does KVM fall back to the old shadow MMU for the nested VMs, and that is exactly where the bugs are. The second precondition is root inside the guest. On a vServer, every customer has root, that is the whole point of a root server. For an attacker, this hurdle is already cleared the moment they order a vServer.
At Prepaid-Hoster, nested virtualization has always been disabled on all hosts. This attack path was therefore never open with us.
And what nobody has found yet
Januscape and Zapscape have been patched. The real problem is a different one: both bugs went unnoticed in the kernel for years, one of them for 16 years. The code path for nested virtualization is old, complex and barely used in normal operation. It would be naive to assume that everything in there has been found by now. And a single escape does not only affect the customer who triggers it, but every VM on the same host.
So our honest answer is: we do not plan to enable nested virtualization on our vServers, and we cannot promise that this will ever change. The risk for all other customers on a host is out of proportion to the benefit for a few.
Do other hosting providers handle this differently?
Some do. But we assume that providers who take their customers’ security seriously handle it the same way we do: nested virtualization stays off on shared hosts. If your provider offers this feature on vServers, it is worth asking how they deal with vulnerabilities like Januscape and Zapscape.
Fair resource usage
There is a second reason as well: virtual servers are built to distribute load at a low price. An additional virtualization layer costs extra performance and makes the load on a host hard to plan. Without nested virtualization, performance stays stable for all customers on a host.
Can I use Docker?
Yes. Docker does not need hardware virtualization, because containers share the kernel of your vServer. Docker runs on our KVM vServers without restrictions. You can find the setup in Can I Use Docker on My vServer?
The same goes for other container solutions like LXC or Podman. For many cases where people instinctively think of a VM (separate services, test environments, several projects on one server), containers are perfectly sufficient.
Pure software emulation, for example QEMU without KVM acceleration, does start without AMD-V or VT-x. For serious use, however, it is far too slow.
The solution for your own VMs: dedicated servers
If you really need your own virtual machines, for example for Proxmox, Hyper-V, a homelab in the data center or VMs for your own customers, go for a dedicated server. There the entire hardware is yours, and AMD-V or Intel VT-x are available without restrictions.
And this also makes sense from a security point of view: on a dedicated server you share the hypervisor with nobody. Even if an escape were to happen in one of your VMs, it would only affect your own system and no other customers. Whether all patches are installed is up to you.
- Around 100 configurations, locations Falkenstein and Nuremberg
- Prepaid as usual, no contract lock-in
- Delivered in rescue mode, installation via the Dedicated Cloud Manager
- Unmanaged: we take care of the hardware and its availability, you manage the operating system and your VMs
Whether your preferred configuration supports virtualization is covered in Does my dedicated server support virtualization?
Further reading
