PwnEscape (CVE-2026-99999): Patched kernels available in testing

A new Linux kernel vulnerability, nicknamed PwnEscape (CVE-2026-99999), has been disclosed. It is a guest-to-host virtual machine (VM) escape: anyone who controls a guest VM can send specially crafted network packets that leak the host’s kernel memory, crash the host, or, as the researcher demonstrated in their own lab, run code as root on the host. Both Red Hat and the Linux kernel CVE team rate it Critical. AlmaLinux 8, 9, and 10 are affected. Patched kernels are available in the testing repository today, and we would like your help verifying them before we release them to production.

If you run AlmaLinux as a host for VMs that belong to anyone you don’t fully trust (a public or private cloud, a VPS/VM provider, or a code sandbox platform), this is especially relevant to you.

More information about the vulnerability:

• CVE record: https://www.cve.org/CVERecord?id=CVE-2026-99999
• Red Hat CVE page: https://access.redhat.com/security/cve/CVE-2026-99999
• Linux kernel CVE team announcement: https://git.kernel.org/pub/scm/linux/security/vulns.git/plain/cve/published/2026/CVE-2026-99999.mbox
• Researcher write-up from PWNAI Research: https://pwn.ai/blog/pwnescape
• Vercel’s summary of the finding: https://vercel.com/blog/findings-from-the-1-million-dollar-vercel-sandbox-challenge#the-kernel-zero-day
• Upstream kernel fix: ipv4: validate checksum_start before completing checksum (commit 6785011f8b16)

Summary

Despite the name, PwnEscape is not a bug in KVM. It lives in the host kernel’s IPv4 networking stack.

When a guest sends a packet through a virtio network device, it can pass the host some metadata along with it, including where in the packet a checksum still needs to be calculated and written. This is called checksum offload, and it saves the guest from doing that work itself. The host kernel trusted that metadata without checking it against the packet’s IPv4 header. With bad checksum metadata, the host’s checksum code ends up writing over an IPv4 header the kernel has already read and acted on. In the researcher’s example, the header length field changed from 5 to 15, so the host’s IP fragmentation code treated a 20-byte header as 60 bytes.

From there, the researcher showed three outcomes:

• A repeatable leak of host kernel memory back to the attacker, for as long as the guest keeps sending packets. Vercel reports this was demonstrated against its production sandboxes.
• A crash of the host, taking down every VM running on it.
• Writes into host kernel memory, chained into running a program as root on the host. This was shown on the researcher’s own KVM and Firecracker machines, and the full details are being held back for a follow-up write-up.

The flaw is old. The upstream fix traces it back to two commits: virtio network header support for tun/tap devices, added in 2008 (Linux 2.6.27), and checksum offload support for packet sockets, added in 2010. That puts the vulnerable code in the kernel for roughly 18 years, and in every kernel AlmaLinux has shipped to date.

Paulos Yibelo of PWNAI Research found the bug during Vercel’s public sandbox security challenge and reported it privately to the kernel security contact and networking maintainers on 2026-09-04. The fix, written by Michael S. Tsirkin of Red Hat, checks that the checksum location is valid before the kernel completes the checksum. It was merged into the mainline kernel on 2026-10-14. Upstream describes it as a defense-in-depth measure: packets like these should not be accepted in the first place, and more complete validation of incoming packets is still being worked on.

Impact

Every supported AlmaLinux release (8, 9, and 10) ships the vulnerable code. The systems most at risk are virtualization hosts that run guests for other people: anyone who controls one of those guests can attack the host and, through it, every other guest on the machine.

This is not only a concern for virtualization hosts. Red Hat’s assessment notes that a local attacker can also trigger the flaw, not just a guest VM, and the vulnerable code is in every AlmaLinux kernel whether or not the system runs VMs. We recommend updating every system. Neither the researcher, upstream, nor Red Hat has published a workaround. The fix is the patched kernel.

Patching ahead of our upstream

Security is a top priority at AlmaLinux. A flaw that lets a guest read, crash, or take over the host it runs on, present in the kernel for nearly two decades, is something that necessitates handling with urgency. At the time of writing, Red Hat lists RHEL 8, 9, and 10 as affected with no fix released yet. Our core team has backported the upstream fix to every affected AlmaLinux branch. The decision to ship ahead of a CentOS Stream / RHEL update was made by our technical steering committee, ALESCo.

These kernels are available in the testing repository today. After the community has helped verify them, we will release them to the production repositories. This post will be updated when that happens.

Patched kernel versions

• AlmaLinux 8: kernel-4.18.0-553.174.2.el8_10
• AlmaLinux 9: kernel-5.14.0-687.57.2.el9_8
• AlmaLinux 10: kernel-6.12.0-211.66.2.el10_2
• AlmaLinux Kitten 10: the fix will ride along in the next regular kernel update, so no separate build is being made

Install the version listed for your release, or higher.

Help us test

sudo dnf install -y almalinux-release-testing
sudo dnf update 'kernel*' --enablerepo=almalinux-testing
sudo reboot

Confirm with uname -r or rpm -q kernel against the versions above. On a virtualization host, rebooting interrupts every guest on it, so migrate or shut down your guests first.

If you do not want the testing repo enabled afterwards (and on a production box you almost certainly do not), disable it once you have rebooted:

sudo dnf config-manager --disable almalinux-testing

If you run into anything, please let us know in AlmaLinux chat or on bugs.almalinux.org.

Thanks

Thanks to Paulos Yibelo and PWNAI Research for finding, analyzing, and responsibly reporting this vulnerability, to Michael S. Tsirkin for writing the upstream fix, and to the kernel networking maintainers for reviewing and merging it. Thanks as well to Vercel, whose sandbox security challenge surfaced the bug, for notifying other affected providers.

Thanks to the AlmaLinux core team for turning around patched builds for every affected release, and to ALESCo for moving quickly to approve shipping ahead of upstream. And thank you in advance to everyone in the community who helps us test these kernels. That’s the part that gets them safely into production.

Stay informed

Remaining aware of these vulnerabilities and acting quickly can keep your systems and data safe. Follow the AlmaLinux Blog, join the Mattermost Community Chat, and subscribe to the Announce and Security mailing lists to stay informed. We will update this post when the patched kernels move from testing to production.

Changelog

• 2026-10-16 20:17 UTC: Initial post published. Patched kernels available in almalinux-testing for AlmaLinux 8, 9, and 10.