AlmaLinux published an advisory on 16 October for CVE-2026-99999, nicknamed PwnEscape, which it describes as "a guest-to-host virtual machine (VM) escape". Red Hat and the Linux kernel CVE team both rate it critical.

The second sentence of that advisory is the one that matters: "Despite the name, PwnEscape is not a bug in KVM."

Where the bug actually is

It is in the host kernel's IPv4 networking stack. A guest sends checksum-offload metadata through a virtio network device, and, as AlmaLinux puts it, "The host kernel trusted that metadata without checking it against the packet's IPv4 header."

The resulting write lands on an IPv4 header the kernel has already read and acted on. In the researcher's example a header length field changes from 5 to 15, and the kernel proceeds on the basis of what it read before the change.

The vulnerable code is old. AlmaLinux traces it to virtio net header support for tun and tap in 2008 and checksum offload for packet sockets in 2010, which is roughly eighteen years.

What a guest can do with it, per the researcher: repeatedly leak host kernel memory, crash the host and take down every virtual machine on it, or write into host kernel memory and chain that into running code as root on the host. The last of those was demonstrated only on the researcher's own KVM and Firecracker machines, and the full details are being withheld.

It was found by Paulos Yibelo of pwn.ai during Vercel's sandbox challenge, using an AI-assisted harness. Vercel confirmed the memory leak against its production sandboxes and says no customer data was accessed.

Why the location of the bug is the whole story

If this were a KVM flaw, the mental model most people have would work: the hypervisor is the boundary, the boundary had a hole, patch the hypervisor.

Because it is in the host's network stack, the model that fails is the tenant's. If you rent a virtual machine, you cannot fix this. Updating your guest kernel does nothing, because the code being attacked is not running in your guest. Your exposure is entirely a function of whether your provider has patched a kernel you cannot see and cannot query.

That is an uncomfortable position and it is the normal one. It is worth saying out loud on a day when it is visible.

The inverse holds too, and AlmaLinux says it: if you run virtualisation hosts for other people, you are the one at risk, and your guests are the attack surface. Red Hat notes a local attacker can trigger the flaw as well, which is why AlmaLinux recommends updating every system rather than only hypervisors.

The fix, and who shipped it first

The upstream commit is 6785011f8b16, titled "ipv4: validate checksum_start before completing checksum", merged to mainline on 14 October. AlmaLinux calls it "a defense-in-depth measure" and says more complete packet validation is still in progress, which is a careful way of saying this closes the demonstrated path rather than the class.

Patched kernels are in AlmaLinux's testing repository now: 4.18.0-553.174.2.el8_10 for AlmaLinux 8, 5.14.0-687.57.2.el9_8 for 9, and 6.12.0-211.66.2.el10_2 for 10. AlmaLinux says it backported the fix ahead of CentOS Stream and RHEL, with its governing committee approving the early release.

At the time of that advisory, Red Hat listed RHEL 8, 9 and 10 as affected with no fix released. A downstream rebuild shipping a critical kernel fix before the upstream vendor is not the usual direction of travel, and it is the practical argument for the rebuild distributions existing.

There is no workaround. AlmaLinux states that neither the researcher, upstream, nor Red Hat has published one.

What to do

  • If you run hosts for other people, patch them. Migrate or shut down guests before rebooting, because a host reboot interrupts every guest on it.
  • If you rent virtual machines, ask your provider whether their hosts are patched, and treat a non-answer as an answer. There is nothing you can do inside your instance.
  • Do not wait for a hypervisor update. There is not going to be one, because the bug is not in the hypervisor.
  • Patch non-virtualised systems too. Red Hat's note about local triggering means this is not purely a virtualisation story.
  • If you are on AlmaLinux, the patched kernels are in testing rather than production. Decide which risk you prefer and make it a decision rather than a default.

What is not established

  • The exact impact beyond the memory leak in the wild. The crash and the root execution were shown on the researcher's own machines, configured to match a production setup.
  • The full technical detail, which is being held back for a follow-up write-up.
  • Whether it has been exploited by anyone other than the researcher. Nothing has been published either way.
  • Whether the defence-in-depth commit closes every path. AlmaLinux says more complete validation is still in progress.
  • When Red Hat will ship, and therefore when the many distributions downstream of it will.
  • The CVSS number. AlmaLinux gives none; the 9.3 circulating comes from the published record rather than from the advisory we read.