Every cloud tenant lives behind one promise: your virtual machine cannot touch the host, and the host cannot be reached by the tenant next door. CVE-2026-99999, nicknamed PwnEscape, breaks that promise, and the break is not where anyone was looking. The flaw is not in KVM. It is in the host kernel's IPv4 networking code, in a checksum optimization that trusted metadata supplied by the guest.
TL;DR
-
What: A Linux kernel flaw in IPv4 checksum offload handling. A guest VM sends packets with crafted checksum metadata; the host kernel's
skb_checksum_help()then writes out of bounds and rewrites an IPv4 header it had already validated (CWE-787). - Impact: Host memory disclosure, host crash, and, demonstrated in the researcher's lab, controlled host-kernel writes and root-level code execution on the host. A guest-to-host escape primitive.
- Severity: 9.3 Critical on the CVE.org record; Red Hat scores it 8.8. The disagreement is one CVSS metric (privileges required).
- Affected: KVM hosts on unpatched kernels 4.4 through 6.18 that pass guest traffic through virtio-net/TAP. AWS says its managed services (EC2, Lambda, Fargate) are not affected; self-managed KVM is the exposure.
- Exploitation status: No public exploit and no reported in-the-wild use as of publication. Red Hat says it is tracking the flaw as an active-exploit case; it is not in CISA's Known Exploited Vulnerabilities catalog (catalog of 2026-10-21, checked 2026-10-22). Those are different statements, and the difference matters.
How a checksum rewrites a header
Checksum offloading exists to save CPU: instead of checksumming a packet immediately, the kernel defers the work and records where the calculation should start and where the result belongs. That metadata travels in the packet buffer (sk_buff) as csum_start and csum_offset.
In a virtualized setup, the metadata arrives from the guest. The host kernel trusted it without checking it against the packet it described.
The sequence is the bug:
- A packet arrives from a guest over virtio-net/TAP. The host parses its IPv4 header normally: version 4, header length 20 bytes (
0x45). Routing and fragmentation decisions are made on those values. - Later, fragmentation calls
skb_checksum_help()to complete the deferred checksum. Working from the guest-suppliedcsum_start, it writes into memory that overlaps the already-parsed IPv4 header. - In the researcher's demonstration, the first header byte changes from
0x45to0x4f. The version nibble is unchanged, so the packet is still IPv4, but the header-length field now reads 15 instead of 5: a 20-byte header is suddenly interpreted as 60 bytes. Fragmentation then treats bytes beyond the real header, bytes the attacker controls, as IPv4 options.
From that primitive, the researchers demonstrated repeated 32-byte disclosures of host memory, a two-packet host crash, controlled writes into host kernel memory, and a chain to root code execution on the host across four cold boots in their own lab. Against Vercel's production sandboxes, the memory-disclosure stage is what was confirmed. Nobody is claiming a production cloud was rooted, and neither are we.
It is a time-of-check/time-of-use shape: state that was validated early is altered later by data that crossed a trust boundary in between. The vulnerable pattern is old; some coverage puts it at roughly 18 years in the tree.
Timeline
- August 2026: Paulos Yibelo of pwn.ai finds the flaw during Vercel's $1 million Sandbox security challenge; the initial memory-disclosure report goes to Vercel on August 20.
- September 4, 2026: Root cause privately reported to the Linux kernel maintainers.
-
October 8, 2026: Fix lands in net.git, commit
6785011f8b16("ipv4: validate checksum_start before completing checksum"). - October 14–15, 2026: Fix reaches mainline; the kernel CVE team announces CVE-2026-99999 publicly on October 15.
The score disagreement, briefly
The CVE.org record scores PwnEscape 9.3 (AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). Red Hat scores it 8.8, differing only on privileges required (Low vs None). Both agree on what matters operationally: the attack is local to a guest, needs no host credentials, and changes scope, meaning the vulnerable component and the impacted component are different machines. On any multi-tenant host, "the attacker must already run code in a guest" describes every tenant you have.
What our index can and cannot tell you
We run cl0q, an independent search engine that maps the public web: 48,321,576 domains and 35,364,497 pages in our current index snapshot (generated 2026-10-26 01:35 UTC, sample-based, approximate).
We cannot see kernel versions from the web, and we will not pretend otherwise. No banner grab tells you whether a host has applied commit 6785011f8b16. Anyone selling you a per-domain "PwnEscape vulnerable: yes/no" list built from web crawling is inventing it.
What the index does show is how concentrated the exposure decision is. Web hosting runs on a small number of networks, and most of them are virtualization-heavy:
| Hosting network | Domains in the index |
|---|---|
| Cloudflare (AS13335) | 7,611,200 |
| Amazon (AS16509 + AS14618) | 3,472,400 |
| OVH (AS16276) | 1,095,550 |
| Google (AS15169) | 1,013,150 |
| Squarespace (AS53831) | 997,250 |
The five largest networks alone account for roughly 29% of all domains we index. For most of the web, the question "is my host patched?" is really "has my provider's kernel program shipped the fix?", and it is answered by a handful of operators. If you run your own KVM hosts, on rented bare metal or your own racks, that answer is yours to produce, and the fix is a kernel update, not a config change.
You can look up any domain's dossier on cl0q to see the hosting network it sits on: cl0q.com/site/example.com. That tells you whose patch status your exposure rides on. For bulk work across a portfolio, the same data is in our datasets and API.
What to do
-
Patch KVM hosts first, guests second. The vulnerable code runs on the host. Update hosts to a kernel carrying commit
6785011f8b16or your distribution's backport. Amazon Linux has published fixed packages (for example kernel-5.10.269-270.1108.amzn2 and kernel-6.1.188-233.385.amzn2023); Red Hat's fixes were still in progress at disclosure. - Prioritize multi-tenant and sandbox hosts. A single-tenant host you fully control is a different risk from a host running untrusted workloads. Sandboxes, CI runners, and shared hosting are the front of the queue.
- Do not wait for a KEV listing. The catalog lags confirmed exploitation routinely; Red Hat is already tracking this as an active-exploit case. Patch on the disclosure, not on the listing.
- Know where your sites actually live. Inventory your domains' hosting networks (the dossiers above do this one by one) so a provider's patch advisory maps to your properties immediately.
The lesson worth keeping
Isolation boundaries are not just the hypervisor. They are every optimization that moves data across the boundary on trust: checksum offload today, another offload tomorrow. PwnEscape sat in one of the most-read code paths in computing, packet forwarding, for years, because the metadata about the packet was never treated as hostile. Anything a guest can influence is input. Validate it like input.
cl0q is a free, independent web search engine with its own crawler and index: cl0q.com. Sources for this article, including the Red Hat and AWS advisories, the SOC Prime analysis, and our CISA KEV check, are listed in the research notes we keep with this draft.
Top comments (1)
Fascinating vulnerability! The fact that this lives in the host kernel IPv4 stack rather than KVM itself is a stark reminder that the virtualization boundary is often assumed to be deeper than it actually is. One thought from the ops side: for environments where CVE-2026-99999 mitigation is not yet available, limiting guest networking capabilities or using isolated network namespaces can reduce the attack surface until patching is possible. Thanks for writing this up with the technical depth it deserves.