PwnEscape (CVE-2026-99999): Patched kernels released

Update: Patched kernels are now in production

2026-10-23 17:16 UTC: Kernels with the PwnEscape fix are now in the production repositories for AlmaLinux 8, 9, and 10. You no longer need to enable the testing repo. Just run:

sudo dnf clean metadata && sudo dnf upgrade
sudo reboot

The fixed versions in production are kernel-4.18.0-553.177.1.el8_10 (AlmaLinux 8), kernel-5.14.0-687.59.1.el9_8 (AlmaLinux 9), and kernel-6.12.0-211.67.1.el10_2 (AlmaLinux 10), or higher. These are newer than the kernels we released to testing. Red Hat has since released its own fix for RHEL 9 and 10, so the AlmaLinux 9 and 10 kernels carry Red Hat’s fix. RHEL 8 is still waiting for one, so the AlmaLinux 8 kernel carries our backport on top of the latest RHEL 8 kernel.

Confirm you are running a patched kernel with uname -r after rebooting. On a virtualization host, migrate or shut down your guests first. Most mirrors sync every few hours, so if the update is not available to you yet, try again a little later.

If you enabled the testing repo to help us test, you can disable it again:

sudo dnf config-manager --disable almalinux-testing

The testing-repo instructions further down in this post remain for reference but are no longer the recommended path. Thanks to everyone who helped test the kernels while they were 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. The Linux kernel CVE team rates it Critical, and Red Hat rates it Important. AlmaLinux 8, 9, and 10 are affected. Patched kernels are now available in the production repositories.

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.

Our patched kernels were first released to the testing repository on 2026-10-16 for community verification. Red Hat has since released fixes for RHEL 9 and 10, and the fix is now in production for every affected AlmaLinux release.

Patched kernel versions

• AlmaLinux 8: kernel-4.18.0-553.177.1.el8_10
• AlmaLinux 9: kernel-5.14.0-687.59.1.el9_8
• AlmaLinux 10: kernel-6.12.0-211.67.1.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. The kernels we first released to testing (kernel-4.18.0-553.174.2.el8_10, kernel-5.14.0-687.57.2.el9_8, and kernel-6.12.0-211.66.2.el10_2) also contain the fix, and the production kernels above replace them. On AlmaLinux 9, kernel-5.14.0-687.58.1.el9_8 is newer than the testing kernel but does not contain the fix.

Installing from the testing repository (historical, for reference)

These instructions are preserved from when the kernels were in testing. The fix is now in production, so the dnf upgrade command at the top of this post is the recommended path.

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 to everyone in the community who helped test them.

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.

Changelog

• 2026-10-23 17:16 UTC: Fix released to the production repositories for AlmaLinux 8, 9, and 10: our backport in kernel-4.18.0-553.177.1.el8_10, and Red Hat’s fix in kernel-5.14.0-687.59.1.el9_8 and kernel-6.12.0-211.67.1.el10_2. Update notice added at the top of the post, kernel versions updated, Red Hat’s rating corrected to Important, and post title updated.

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