PwnEscape CVE-2026-99999: Linux Kernel Guest-to-Host Escape, Patch VM Hosts Now

TL;DR. PwnEscape (CVE-2026-99999) is a Linux kernel flaw in IPv4 packet handling that lets a guest virtual machine attack the host it runs on. The researcher showed it leaking host memory, crashing the host and, in their own lab, running code as root on the host. The Linux kernel CVE team rates it CVSS 3.1 9.3 Critical; Red Hat rates it Important (8.8). Fixed kernels have been out since 15 October and Red Hat, AlmaLinux and Debian have shipped them. Ubuntu has not released a fix yet. The bug sits in code added in 2008 (Linux 2.6.27), so almost any Linux host is in range. Patch the host kernels of anything that runs other people's VMs, sandboxes or containers, and reboot. Patching guests does not protect the host.

What lowers urgency, and the catch

Not remote by itself. The attacker needs code running inside a guest VM or a local position on the machine. The kernel CVE team scores it as a local attack and calls the trigger a "guest/local virtual-device path, not an Internet receive path" ( CVE record ). Akamai, which patched its own hypervisors, agrees the flaw "cannot be exploited remotely by itself" ( Akamai ).

No reported attacks and no public exploit. CISA's assessment on the CVE record lists exploitation as "none" ( CVE record ). CVE-2026-99999 is not in KEV as of our check (see Sources). The researcher has not published exploit code and is holding back the code-execution details for a second write-up ( pwn.ai ).

Fixes exist. Upstream stable kernels, Red Hat Enterprise Linux 6 ELS through 10, AlmaLinux 8, 9 and 10, and Debian all have fixed packages.

Multi-tenant hosts are the target. Anyone who controls one guest can attack the host and, through it, every other guest on the machine. Cloud and VPS hosts, CI runners, code sandboxes and AI-agent execution platforms built on KVM or Firecracker carry the most risk.

The clock is short. The researcher writes that they "expect exploits in weaker configurations to arrive in weeks, and exploits working in default hypervisor configurations to arrive in under a month" ( pwn.ai ).

Ubuntu is not patched yet. As of our 31 October check (page last updated 30 October), Ubuntu lists every supported release as vulnerable, with fixes "work in progress" for 22.04 and later, and rates the issue priority Medium ( Ubuntu ).

Paulos Yibelo of PWNAI Research found the bug in August during Vercel's public $1 million Sandbox security challenge. Vercel calls it the program's most important report and says the memory leak was "demonstrated against Vercel production sandboxes", while the crash and code-execution attacks ran on the researcher's own KVM and Firecracker machines ( Vercel ). The researcher reported the root cause privately to the kernel security contacts on 4 September ( pwn.ai ).

Michael S. Tsirkin of Red Hat wrote the accepted fix, "ipv4: validate checksum_start before completing checksum" (commit 6785011f8b16). It reached the mainline kernel on 14 October, and seven stable kernels carrying it shipped on 15 October ( LWN ). The kernel CVE team published CVE-2026-99999 the same day ( kernel CVE announcement ), and the flaw was posted to the oss-security list that evening ( oss-security ).

Despite the "KVM escape" label in the researcher's write-up, AlmaLinux stresses that "PwnEscape is not a bug in KVM. It lives in the host kernel's IPv4 networking stack" ( AlmaLinux ).

PwnEscape is a separate issue from the Linux TCP use-after-free CVE-2026-98432 and the Fragnesia flaw CVE-2026-46300 we covered earlier. Patching for those does not cover this one unless your new kernel build lists CVE-2026-99999.

Technical Information

Linux can carry a packet whose checksum is still to be filled in later, a performance feature called checksum offload. The packet carries two hints: where the checksum calculation starts and where the result should be written. A guest VM using a virtio network card can pass these hints to the host along with its packets.

The host kernel did not check that the start position lay after the packet's IPv4 header. With bad hints, the kernel's checksum helper writes into an IPv4 header the kernel has already checked and acted on. In the researcher's example, the header-length field changes from 5 to 15, so the host's fragmentation code treats a 20-byte header as 60 bytes ( AlmaLinux ). The kernel CVE team's scoring notes describe the path: crafted metadata from a microVM reaches the host's TAP device and the IPv4 fragmentation code, a "guest/local virtual-device path, not an Internet receive path" ( CVE record ).

Three outcomes were demonstrated, per the researcher and Vercel:

Host memory leak. Host kernel memory shows up in packets the guest sends, repeatedly, for as long as the guest keeps sending.

Host crash. Two packets took the host down, and every sandbox on it.

Host code execution. Controlled writes into host kernel memory, chained into running a program as root on the host. This was shown only on researcher-owned machines.

Red Hat adds that "a local attacker or untrusted guest virtual machine" can trigger the flaw, so it is not limited to virtualization hosts ( Red Hat ). Akamai says removing the CAP_NET_RAW capability from untrusted containers "will help mitigate at least some of the known vulnerability vectors" ( Akamai ).

The fix adds one check, in six kernel files, that the checksum start position is valid before the checksum is completed. The commit calls it "defence in depth" and says "a more complete validation at input is forthcoming" ( upstream commit ). Expect follow-up patches.

Timeline (Cyprus time; EEST, UTC+3 until 25 October, EET, UTC+2 after):

18–20 August: Vercel opens its Sandbox challenge; the researcher files the first memory-leak report two days later.

4 September: Root cause reported privately to kernel maintainers, with candidate patches.

14 October: Fix merged into the mainline kernel. Vercel publishes its challenge findings.

15 October, 15:19: Kernel CVE team publishes CVE-2026-99999 with seven fixed stable kernels. 22:25: oss-security post.

16 October, 18:49: CISA adds its assessment (exploitation "none"). 23:17: AlmaLinux releases test kernels.

19–20 October: Red Hat fixes RHEL 10 and RHEL 9.

23 October, 20:16: AlmaLinux moves fixed kernels for 8, 9 and 10 to production.

24 October: Red Hat fixes RHEL 8 (RHSA-2026:89083).

27 October: Red Hat fixes RHEL 6 ELS and OpenShift 4.12 to 4.22.

29 October: Akamai publishes mitigation guidance; NetApp updates its advisory.

30 October, 22:06: Ubuntu's CVE page is updated, still with no released fix.

Red Hat's CVE page says "Red Hat tracks this flaw as a KEV active-exploit case" ( Red Hat ). That is Red Hat's wording. CISA has not added CVE-2026-99999 to its catalog, and we found no public report of attacks.

Affected Product Versions

Upstream, the flaw affects kernels from 2.6.27 up to the fixed stable versions below ( kernel CVE announcement ).

Distribution status as of 31 October, 01:35 Cyprus time (EET, UTC+2):

AlmaLinux shipped first. AlmaLinux backported the fix to AlmaLinux 8 on 23 October, when it wrote that "RHEL 8 is still waiting for one". Red Hat's RHEL 8 fix followed on 24 October. AlmaLinux also warns that kernel-5.14.0-687.58.1.el9_8 is newer than its test kernel "but does not contain the fix" ( AlmaLinux ).

Debian lists the fixed packages on its security tracker .

Appliances run Linux too. NetApp's advisory, still marked interim, lists several products under investigation, including baseboard management controllers and SolidFire/HCI nodes, and says "None at this time" for workarounds ( NetApp ).

Managed platforms. Akamai says it has patched its hypervisors, but customers must patch their own VMs and Kubernetes nodes. Its Ubuntu-based LKE Enterprise nodes were still waiting on Canonical on 29 October.

Find exposure and patch

List your hosts that run code you do not fully trust: hypervisors, VPS and cloud hosts, CI/CD runners, sandbox and AI-agent platforms, Kubernetes nodes with multi-tenant workloads, and hosts running nested virtualization. These come first.

Check the running kernel , not only the installed package. Run uname -r and compare it with the table above or your distribution's advisory. A fixed package does nothing until the host reboots into it.

Patch and reboot the host. On a virtualization host, migrate or shut down guests first. Updating guest kernels alone leaves the host exposed.

Update guests and container nodes as well. Akamai says guest kernels "may also be vulnerable" through less-privileged containers or nested virtualization.

For Ubuntu fleets, plan for the gap. Watch the Ubuntu CVE page and patch as soon as kernels land. In the meantime, move untrusted workloads off Ubuntu hosts where you can, and drop CAP_NET_RAW (and CAP_NET_ADMIN ) from untrusted containers. (Rescana guidance, based on Akamai's advice.)

Reduce attack surface. Vercel's post-challenge steps include keeping host and guest kernels current, disabling nested virtualization and running each Firecracker microVM under its jailer.

No vendor offers a full workaround. Red Hat says mitigations "do not meet the Red Hat Product Security criteria". The patched kernel is the fix.

Indicators of Compromise

No source has published indicators of compromise: no hashes, IP addresses or domains. Things worth reviewing on exposed hosts (Rescana guidance, low fidelity) :

Host kernel warnings, oopses or panics involving skb_checksum_help or ip_do_fragment since 15 October.

Unplanned reboots of multi-tenant hosts, especially where several guests went down together.

IPv4 fragments leaving the host from a guest with unexpected IP options or header lengths.

A clean result does not prove a host was not targeted. The memory leak leaves little trace.

We will update this advisory if:

CISA adds CVE-2026-99999 to KEV, or any vendor or CERT reports attacks.

Public exploit code or the researcher's second write-up appears.

Ubuntu releases fixed kernels.

NVD publishes its own score.

Follow-up kernel fixes for incoming packet validation get CVEs.

Major cloud or sandbox providers publish statements.

Why this matters for your vendors

Your vendors run your data on shared Linux hosts: cloud and hosting providers, CI/CD services, code-execution and AI-agent platforms, managed Kubernetes and storage appliances. A single malicious tenant on an unpatched host could read memory from, or take over, the machine your workload shares. Questions to send:

Are the host kernels behind our service patched for CVE-2026-99999, and have those hosts been rebooted into the fixed kernel? On what date?

Do you run untrusted or customer-supplied code in VMs, microVMs or containers? If so, how do you isolate it, and do those workloads have CAP_NET_RAW or CAP_NET_ADMIN ?

Do any of your hosts run Ubuntu? What is your plan until Canonical ships a fixed kernel?

Do your appliances or management controllers (BMC, storage, network) run affected Linux kernels, and have their makers published fixes?

Have you seen unexplained host crashes or kernel warnings in packet checksum or fragmentation code since 15 October?

Will you tell us if you find signs that this flaw was used against infrastructure that hosts our data?

If you want help working out which of your vendors run shared Linux infrastructure and asking them these questions, talk to Rescana .

Linux kernel CVE team, CVE-2026-99999 announcement:

Upstream fix, commit 6785011f8b16:

CVE record (kernel CNA score, CISA assessment):

NVD:

Red Hat CVE page:

Red Hat RHSA-2026:86089 (RHEL 9.4):

Red Hat RHSA-2026:89083 (RHEL 8):

AlmaLinux:

Ubuntu:

Debian security tracker:

NetApp NTAP-20261021-0001:

Akamai (Linode) mitigation guide:

CISA Known Exploited Vulnerabilities catalog (checked 31 October 2026, 01:32 Cyprus time, catalog version 2026.10.30; CVE-2026-99999 not in KEV):

Researcher write-up, PWNAI Research:

Vercel, Sandbox challenge findings:

oss-security post:

LWN, stable kernels: