A flaw in the Linux kernel’s IPv4 packet processing, dubbed PwnEscape and tracked as CVE-2026-99999, lets code running inside a virtual machine tamper with packets after the host kernel has validated them, leaking host memory and, in lab conditions, crashing or taking over the host. Researcher Paulos Yibelo of pwn.ai found it during Vercel’s $1 million Sandbox security challenge and demonstrated the memory-leak stage against Vercel’s production sandboxes. Vercel confirmed the leak and reported no evidence that customer files, secrets or application data were exposed.

Technical details

The bug is not in KVM, Firecracker or any single cloud platform. It sits in the host kernel’s handling of checksum-offload metadata supplied by a guest. With virtio-net and TAP networking, a guest can attach partial-checksum metadata to an outgoing packet. The host kernel did not sufficiently validate that metadata against the IPv4 header before completing the deferred checksum calculation.

The result is a write primitive that lands in an IPv4 header the kernel has already read and acted on. In the researcher’s example, the header length field was flipped from 5 to 15 after validation. Downstream code then trusts a header it believes was already checked, and each outgoing packet can carry roughly 32 bytes of adjacent host memory back to the guest.

According to the write-up, the exploit chain has three stages:

  1. Host memory leak — repeated packets exfiltrate host kernel memory. This is the only stage shown against production infrastructure.
  2. Host crash — two crafted packets were enough to crash a host in lab testing.
  3. Host code execution — root code execution was demonstrated only on researcher-controlled machines.

The upstream fix is commit 6785011f8b16, ipv4: validate checksum_start before completing checksum, authored by Red Hat’s Michael S. Tsirkin. The commit message describes it as defense-in-depth and notes that broader ingress validation still needs work, so expect follow-up patches. The report went to the kernel security contact and networking maintainers on 2026-09-04.

Affected systems

Reports put the exposed range at Linux kernels from 4.4 through 6.18 on self-managed KVM hosts using virtio-net with TAP networking, which includes Firecracker-style microVM setups. AWS reportedly states that its managed EC2, Lambda and Fargate services are not affected. This is not a container escape; the exposure is for operators who run untrusted guests on their own hypervisors: sandbox and code-execution platforms, CI runners that use VMs, VPS hosting providers and private clouds.

Severity ratings differ by source. The kernel CNA record scores it CVSS 3.1 9.3 (Critical), Red Hat rates it 8.8, and NVD has not completed its own assessment. The vulnerability is not in CISA’s KEV catalog and there are no reports of exploitation in the wild.

Mitigation

  • Patch the host kernel. Stable fixes are in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 and 7.2.11, plus the mainline commit. Check your distribution’s kernel advisory; AlmaLinux has published patched kernels in testing, and VirtFusion and TuxCare have issued guidance for their users.
  • Interim hardening. TuxCare recommends disabling checksum offload on the virtio-net interfaces of untrusted guests on hosts you cannot patch yet. Expect a throughput cost.
  • Prioritize multi-tenant hosts. Any host running guests from different trust domains should go first. Single-tenant hosts where you control every guest are lower risk.
  • Assume kernel memory exposure on unpatched multi-tenant hosts. Leaked host memory can contain keys or data from other tenants; consider rotating host-held secrets where untrusted guests ran on vulnerable kernels.

References