2

Picture an apartment building. The building is your server. Each apartment is a virtual machine (VM) that you rent to a customer. Most tenants are lovely. A few are curious. And once in a while, one of them finds a way to walk through the wall into the building’s control room. That is the kind of problem CVE-2026-99999 creates. Researchers call it PwnEscape. It is a flaw in the Linux kernel, in the part that handles virtio-net and TAP networking. AWS published a bulletin about it (2026-137-AWS) on October 15, 2026, and advice from different vendors keeps changing as new details emerge. This checklist is for VPS providers, data centers, and businesses that run their own KVM hosts. By the end, you will know whether you are exposed, which kernels you really run, whether a fix truly covers them, and how to plan reboots without surprising your customers.

What is CVE-2026-99999 (PwnEscape) and what is its impact?

Let’s break it down in plain words.

• A host is the real server. A guest is a virtual machine running on it.

• The kernel is the core of Linux. It controls everything else.

• A hypervisor (like KVM) is the software that lets many guests share one host.

AWS says a user with admin-level access inside a guest can send specially crafted network packets that corrupt the host’s kernel memory. The attacker can leak host memory or crash the host (a denial of service). The Linux kernel CNA scores it 9.3 out of 10 (critical), mainly because the damage jumps from the guest into the host.

AWS lists the affected systems as KVM hypervisors running unpatched kernels from 4.4 through 6.18, including Firecracker setups.

Is Anyone Attacking with it Right Now?

Here is the honest answer, and we think honesty matters more than drama.

Neither the AWS bulletin nor CloudLinux’s page confirms attacks in the wild. TuxCare reports no public exploit code. The researcher says they achieved code execution on the host in their own test machines, and CloudLinux has not reproduced that. Other security write-ups also point out that the published research explains the packet trick in detail, so don’t treat “no public exploit” as a safety blanket.

So what should you do? Treat it as serious and urgent for hosts with multiple tenants, but not as an active outbreak. Move quickly. There is no need to panic.

Step 1: Are You Actually Affected?

First, split your servers into two groups: those AWS manages and those you manage.

AWS says Amazon EC2, AWS Lambda, and AWS Fargate are not affected and require no customer action. That covers AWS’s own infrastructure. It does not cover a KVM host that you run, whether it sits in your data center, a colo cage, or on Amazon Linux.

You are affected only if all three of these are true:

1. You run KVM or Firecracker on kernels you control.

2. Your guests use virtio-net through TAP or vhost-net.

3. Someone other than you can run privileged code inside a guest.

See the pattern? Your exposure depends on how you set things up, not where your servers live. A ten-rack VPS provider and a private-cloud team face the same bug.

Step 2: How to Check if Your Systems are Vulnerable to CVE-2026-99999

Start with what is running, not what you installed. Those two can be very different.

Run these on each host:

uname -r

lsmod | grep -E ‘kvm|vhost_net|tun’

ls -l /dev/kvm

sysctl user.max_user_namespaces

virsh dumpxml <domain> | grep -A4 ‘<interface’

For every host, write down:

• Running kernel and last reboot date. A fixed kernel that you installed but never booted protects nothing.

• Who your guests are. Untrusted customers, your own internal workloads, or a mix?

• Interface model and offload settings in each guest definition, including any explicit csum= settings.

• /dev/kvm permissions. TuxCare notes that on EL8 to EL10 every user can write to this device by default. That means a shell user on a shared server may be able to boot a VM of their own.

• Unprivileged user namespaces. CloudLinux flags this as an extra route on shared hosts that don’t even run VMs. It has not confirmed that attackers can exploit this route.

Now sort your list. Hosts with untrusted tenants go first. Shared servers with shell users go second. Internal-only hosts go third.

Step 3: Is the Fix Really in Your Kernel?

Amazon Linux

AWS lists these kernels (or newer) as fixed:

• Amazon Linux 2: 4.14.355-287.750, 5.4.302-229.494, 5.10.269-270.1108, 5.15.220-156.256

• Amazon Linux 2023: 6.1.188-233.385, 6.12.110-135.201, 6.18.51-120.162

Every other Linux

For all other distributions, AWS says to take kernel updates from your OS vendor. Watch out for three traps.

Trap 1: Version numbers can fool you. Enterprise vendors “backport” fixes, which means they copy a fix into an older kernel. So vendors can fix an older-looking kernel and still leave a newer-looking one unfixed. Check the vendor advisory or the package changelog:

rpm -q –changelog kernel-$(uname -r) | grep CVE-2026-99999

Why Does the Advice Look so Confusing?

Good question. You will see two things that seem to clash. Both make sense once you look closer.

CloudLinux seems to disagree with itself. Its summary says no fixed kernel and no livepatch have shipped. Later sections describe a KernelCare livepatch for EL9 that is already in the main feed, with EL8 and EL10 still in progress. The page also calls its mitigations partial and untested, and it leaves an unresolved editor’s note beside a verification command that it contradicts one line later. The sensible reading is that the editors keep updating the page as things change. Kernel packages are pending, and livepatch is partial. So check each kernel yourself instead of repeating the summary to customers.

AWS says “no workarounds,” yet others list some. These fit together. AWS means that nothing replaces the kernel update. CloudLinux and TuxCare describe stopgaps, and each one removes only one ingredient the attack needs:

• Turn off checksum offload for untrusted guests. In QEMU, use csum=off,guest_csum=off. In libvirt, add <driver><host csum='off'/><guest csum='off'/></driver> inside the interface. The guest needs a restart, and you lose some speed because the guest loses TSO and GSO. TuxCare says it has not verified whether Firecracker supports this per VM.
• Turn off unprivileged user namespaces with user.max_user_namespaces=0. This only closes the local path. It does nothing for VM guests, and it breaks rootless containers.

Tell your customers these are stopgaps, not fixes. Also expect a second kernel update later. TuxCare quotes the upstream commit as calling the change “defence in depth,” with fuller input checks still to come.

Step 4 : Update, Reboot and Check your Tenant

Follow a controlled rollout to reduce disruption:

1. Start small. Patch one canary host with low-risk tenants. Patch, reboot, check, then move on to the rest.

2. Move guests first. Drain or live-migrate guests before rebooting if your setup allows it. If it doesn’t, tell your customers about the maintenance window early.

3. Reboot every host that received a kernel package. Collect your logs first, because a reboot can erase clues.

4. Check the host. Make sure uname -r and the changelog match the fix, and that dmesg shows no oops (a kernel error message) in the virtio-net or TAP path.

5. Check your tenants. Confirm guest connectivity, DHCP and ARP behavior, and throughput compared with your numbers from before the change. Pay special attention to hosts where you turned offloading off.

6. Keep stopgaps until you confirm the fix on that host. Then remove them to get your speed back.

7. Keep a record for each host: kernel version, advisory reference, and reboot time. Run your inventory again when the follow-up kernel arrives.

You can also review kernel logs for unexpected errors: dmesg -T | grep -Ei ‘oops|panic|virtio|tap’ 

This command helps identify relevant messages, but a clean log does not prove that a host is patched. For larger server fleets, consistent maintenance and monitoring processes make it easier to track outstanding updates. See SupportPRO’s data center support services for related infrastructure support.

What Hosting Providers Should Do Next 

CVE-2026-99999 highlights why KVM host security requires more than installing a kernel package. Hosting providers must identify exposed systems, apply the correct vendor fix, reboot where required, and verify that customer workloads operate normally. Start with hosts that run untrusted tenants, confirm the fix against your distribution’s advisory, and keep a record of every remediated system.

Managing a growing fleet of hosting servers? SupportPRO’s server management team can help with kernel updates, server maintenance, and ongoing infrastructure management.

References:
https://aws.amazon.com/security/security-bulletins/2026-137-aws/
https://blog.cloudlinux.com/cve-2026-99999-guest-to-host-escape
https://tuxcare.com/blog/pwnescape-kvm-guest-escape/