A Linux flaw lets a virtual machine reach its host. Here's who needs to act

If you run your own virtual machines on Linux, with Proxmox, KVM or libvirt, update the host's kernel and reboot it this week. A flaw nicknamed PwnEscape could let someone inside one of those virtual machines reach the machine underneath.

If you rent a virtual server from a hosting company, the fix is mostly their job, not yours. But it's worth five minutes to find out where you stand.

What happened

The flaw is tracked as CVE-2026-99999 and rated 9.3 out of 10. It was made public on 15 October, and The Register covered it today.

In plain English, the bug is in how the Linux kernel handles network traffic. A virtual machine can send packets with bad information attached, and the host's kernel trusts it. The researcher's write-up says plainly that "the vulnerable component is the host networking stack."

Red Hat's page on the flaw lists three possible outcomes: running code on the host, crashing it, or leaking memory the virtual machine should never see. That's the bad one. The whole point of a virtual machine is that it stays in its box.

The researcher hasn't published a working attack. The write-up describes a test on their own machines and holds the details back for a later post.

Does it affect you?

It depends on which side of the virtual machine you're on.

You run virtual machines yourself. Maybe a Proxmox box in the office, or a server running KVM with a handful of guests. You're the host, so this is yours to fix. AWS's bulletin says unpatched kernels from 4.4 to 6.18 are affected, which covers most of the last decade. It also says "There are no workarounds for this issue." Updating the virtual machines themselves doesn't help. The host needs the new kernel.

You rent a virtual server. Your hosting company runs the host, so they're the ones who need to patch. Your server is the guest. The risk is someone else's virtual machine on the same physical server getting at the host. AWS says its own services, including EC2, Lambda and Fargate, are not affected. For other providers, look on their status page or blog for a mention of CVE-2026-99999, or ask their support team.

You're on shared hosting or a managed platform. Nothing for you to do.

You run a plain Linux server with no virtual machines on it. The research only shows the attack coming from a virtual machine, so your risk is much lower. The fix is still in the kernel, though, so install it with your normal updates.

Which version has the fix?

When I checked on 19 October:

• Proxmox VE. Proxmox's advisory, PSA-2026-00068-1, says the fix is in proxmox-kernel-7.0.14-24-pve. A Proxmox staff member says on the forum that the 7.0.14 series is the only one they currently support, so if you're on an older kernel series, it's time to move.
• Debian. The security tracker lists the fix in 6.12.113-1 for Debian 13 (trixie) and 6.1.190-1 for Debian 12 (bookworm).
• Ubuntu. Ubuntu's CVE page still listed every supported release as "Needs evaluation", so no fixed kernel yet. Keep checking.
• Red Hat Enterprise Linux and its rebuilds. Red Hat lists all its current products as affected and says fixes are being worked on.

What to do this week

1. Find out if you're a host. On a Proxmox server, pveversion tells you. On other Linux servers, virsh list --all lists any KVM virtual machines. If neither command exists, you probably aren't running any.

2. Check which kernel is running. This shows the version in use right now:

uname -r

3. Update and reboot the host. On Proxmox and Debian that's apt update && apt full-upgrade, then a reboot. A new kernel does nothing until the machine restarts into it, so run uname -r again afterwards and check the number has changed. Reboot at a quiet time, and remember every virtual machine on the box goes down with it unless you move them first.

4. If you rent a server, ask. A short support ticket is enough: "Have your hosts been patched for CVE-2026-99999?" A good host will either have an answer or point you to an announcement. Some may need to restart hosts to apply it, so watch for a maintenance email.

5. On Ubuntu or Red Hat, keep an eye out. Install the kernel update when it arrives, then reboot. Automatic updates will usually install a new kernel, but they won't normally reboot for you.

The bigger point

Kernel updates are the ones that quietly get left behind. The package installs, everything carries on working, and the server keeps running the old kernel for months because nobody wants to reboot it. A flaw like this is a reminder that "updated" and "running the update" aren't the same thing.

If nobody in your business is going to check which kernel your servers are actually running, that's what a support retainer is for. I keep your servers updated, reboot them when they need it, and tell you about it in plain English.