# PwnEscape: How Untrusted Checksum Metadata Rewrote a Validated Packet Header — and Leaked Host Memory

> The Critical bug from Vercel’s $1M Sandbox challenge — nicknamed PwnEscape by researcher Paulos Yibelo (PWNAI, pwn.ai) — is a Linux-kernel IPv4 networking flaw, not a KVM break. Deferred checksum completion (CHECKSUM_PARTIAL / csum_start) rewrites an IPv4 header AFTER the kernel validated it — a time-of-check/time-of-use on packet metadata. Guest-controlled checksum data mutates the IHL field (0x45→0x4f), so the fragmenter copies roughly 32 bytes of host memory beyond the logical packet into outgoing IP options → host-memory disclosure. Confirmed leaking host memory on Vercel production; host crash and full guest-to-host code execution were demonstrated only in the researcher’s own KVM/Firecracker lab. Fixed upstream in commit 6785011f8b16 and backported across stable kernels; CVE pending. The mechanism, why it matters for multi-tenant isolation, and what defenders should do.

Source: https://playciso.com/blog/pwnescape-linux-ipv4-checksum-host-memory-kvm-isolation · Published: 2026-10-17 · Publisher: PlayCISO (https://playciso.com)

Primary source: https://pwn.ai/blog/pwnescape

---

The most interesting part of the Critical bug from Vercel’s $1,000,000 Sandbox challenge is not that a guest reached the host. It is _how_: not by defeating the hypervisor, but by feeding the host kernel a packet whose own **checksum metadata rewrote a header the kernel had already validated**. Researcher **Paulos Yibelo** of **PWNAI Research** nicknamed it [PwnEscape](https://pwn.ai/blog/pwnescape), and it is best understood as a new flavour of an old bug class — a time-of-check/time-of-use race, but on _packet metadata_ rather than on a file or a pointer. **The one-line version.** This is a **Linux-kernel IPv4 networking flaw**, reachable from inside a guest — _not_ a KVM/Firecracker hypervisor break. It leaks host memory into packets a guest sends. We covered the overall Vercel findings and the hypervisor-vs-kernel framing in [The Vercel Sandbox Escape, One Week On](/blog/kvm-vm-escape-zero-day-vercel-sandbox-multi-tenant-cloud); this post is the **technical mechanism** and what it means for multi-tenant isolation. ## The old assumption: a validated header stays validated When the Linux networking stack receives or builds an IP packet, it validates the header: the version is IPv4, the **IHL (Internet Header Length)** field says how many 32-bit words the header occupies, options are bounded, lengths are sane. Everything downstream — routing, fragmentation, copying bytes out to the wire — trusts that validated header. The implicit contract is simple: _once the header has been checked, it does not change underneath you._ Modern kernels break that contract for a good reason: **performance**. Computing checksums is expensive, so the stack defers it. With `CHECKSUM_PARTIAL`, the kernel records _where_ the checksum should eventually be written using offload metadata — chiefly `csum_start` (the byte offset at which checksum computation begins) and `csum_offset` (where the result lands) — and completes the checksum later, often just before the packet leaves. The completion step **writes back into the packet buffer**. If that write can be aimed at bytes the validator already approved, you have a time-of-check/time-of-use (TOCTOU) window — and the thing being raced is not a file, it is the packet’s own header. ## The mechanism: checksum completion rewrites the IHL nibble Here is the chain, in plain terms: - A guest sends a packet with attacker-chosen checksum-offload metadata. The kernel treats that metadata as a description of where to finish the checksum. - The IPv4 header is validated — at this instant IHL is the normal 0x45 (version 4, header length 5 words = 20 bytes). - Later, deferred checksum completion runs and writes its result into the buffer at the offset the metadata pointed to. Crafted so the write lands on the first header byte, it flips that nibble to 0x4f — IHL now reads 15 words = 60 bytes. - Nothing re-validates. The next stage — the IP fragmenter / header copy — believes the header is 60 bytes and copies 60 bytes out, even though only 20 bytes of real packet existed. - The extra 40 bytes beyond the real header are now treated as IP options, and the copy drags roughly 32 bytes of adjacent host memory into the IP options field of the outgoing packet. The packet the guest emits onto the network now carries a slice of **host kernel memory** it was never supposed to see. Repeat it, and you have a **continuous host-memory disclosure primitive** — a leak you drive from inside the sandbox and read off the wire. ## Why this is a “coordinate mismatch” between layers The root confusion is that two parts of the stack reason about the packet in **different coordinate systems**. The validator reasons about the **L3 (IP) header** — version, IHL, options. The checksum-offload machinery reasons in raw **buffer offsets** set up around the **L2/framing** view of the `skb` — `csum_start` is just “this many bytes into the buffer.” Those two views are supposed to stay consistent, but nothing forced the offload offset to respect the boundaries the L3 validator cared about. When a guest controls the metadata, it controls an offset in one coordinate system that writes into a field that matters in the other — and the validated-header invariant quietly dies. That is the general shape worth remembering: **a deferred, metadata-driven write that lands inside already-validated, security-relevant data**. ## What’s confirmed vs. what’s a lab demonstration **Confirmed in Vercel production:** the **host-memory disclosure** — host memory leaking into packets the guest sends — was demonstrated against Vercel’s **production** environment. State this as fact. **Demonstrated only in the researcher’s own lab:** a **host crash** (denial of service from crafted packets) and **full guest-to-host code execution / sandbox escape** were shown on the researcher’s **own KVM/Firecracker lab** built to match Vercel’s configuration — **not** against Vercel production. **Not a claim:** there is **no claim of root code execution in any vendor’s production environment**. Treat the escape as a lab demonstration, not a confirmed production break. **No customer data:** Vercel states **“No reports showed anyone accessing customer data.”** Hold the two apart deliberately: the _leak_ is the confirmed, real-world consequence; the _crash and escape_ are what the same bug enabled in a controlled lab. A prior write-up in this space got this exact distinction wrong by promoting a lab escape to a production fact — so we are careful here. ## Where PwnEscape sits in the $1M challenge PwnEscape was the single **Critical** in Vercel’s challenge. Per Vercel’s [14 October 2026 findings post](https://vercel.com/blog/findings-from-the-1-million-dollar-vercel-sandbox-challenge), the challenge (run from **August 2026**) drew **1,285 reports**, paid **$242,000**, and counted **57 valid** findings — **one** of which was Critical. This was it. That ratio is itself a security lesson: a seven-figure incentive against a hardened boundary produced exactly one bug that crossed the guest→host line, and it came in through the _kernel_, not the hypervisor. ## Patch now: the fix and the backports The upstream fix is commit **6785011f8b16**, **“ipv4: validate checksum_start before completing checksum,”** authored by kernel developer **Michael S. Tsirkin** and merged by **Jakub Kicinski on 8 October 2026**. It has been **backported across stable kernels**: **5.10, 5.15, 6.1, 6.6, 6.12, 6.18 and 7.2**. The maintainers describe the change as **defense-in-depth**, with fuller input validation of checksum metadata **still forthcoming** — so this is a floor, not the final word. **A CVE is pending** and no CVE identifier is authoritative yet; cite the **commit (6785011f8b16)** as the identifier until the CVE lands. Patch your **host** kernels to a build that carries the backport, and track your distribution’s advisory for the eventual CVE mapping. When the CVE does publish, you can score its environmental impact for your estate with the free [CVSS Calculator →](/tools/cvss-calculator). ## What a security leader should take from the mechanism - ☐ Patch the host kernel — that is the control. The hypervisor did its job; the vulnerable component was the Linux kernel every host runs. Prioritise host-fleet kernel patching to a build with commit 6785011f8b16, and ask providers how fast they patch host kernels, not just hypervisors. - ☐ Treat the shared host kernel as the real tenant boundary. In multi-tenant and sandbox compute, a guest-reachable kernel defect crosses the line your whole isolation story depends on — even when the VM wall holds. Compare how different stacks expose that surface with our hypervisor isolation comparison →. - ☐ Harden the hypervisor host, don’t just trust it. Reduce what an escaped or leaking guest can reach: minimal host kernels, constrained guest-exposed features, egress controls, and no crown-jewel secrets resident on shared hosts. Work the KVM hardening checklist → to harden your hypervisor hosts against exactly this class of guest-reachable kernel bug. - ☐ Assume the leak primitive before the escape. A continuous host-memory disclosure is itself a severe outcome — secrets, keys and neighbouring-tenant data can ride out in packets long before anyone proves code execution. Design so a leak is survivable: tenant-held encryption keys, least privilege, and segmentation that limits co-location blast radius. - ☐ Watch for the broader metadata-TOCTOU class. The lesson generalises beyond IPv4: any deferred, attacker-influenced write into already-validated data is a candidate for the same bug. Re-validate security-relevant fields after any step that can mutate them. ## Credit **Researcher:** Paulos Yibelo, **PWNAI Research** ([pwn.ai](https://pwn.ai)) — technical write-up at [pwn.ai/blog/pwnescape](https://pwn.ai/blog/pwnescape). **Independent primary source:** Vercel, [“Findings from the $1M Vercel Sandbox challenge.”](https://vercel.com/blog/findings-from-the-1-million-dollar-vercel-sandbox-challenge) The fix is upstream Linux commit `6785011f8b16`. ## The takeaway PwnEscape is a reminder that isolation is a _stack_ of boundaries, and the weakest reachable one decides your exposure. Here the hypervisor held and the host’s own kernel — processing a packet whose checksum metadata rewrote a header it had already validated — did not. The confirmed consequence is a host-memory leak on real production; the escape is a lab demonstration, not a production claim. Patch host kernels to the backported fix, treat the shared host kernel as the boundary that actually matters, and harden the host so that a guest-reachable kernel bug is survivable rather than fatal. _Related: the full [Vercel Sandbox findings and the hypervisor-vs-kernel framing](/blog/kvm-vm-escape-zero-day-vercel-sandbox-multi-tenant-cloud). Compare isolation designs with the [hypervisor comparison](/tools/hypervisor-comparison), harden your hosts with the [KVM hardening checklist](/tools/kvm-hardening-checklist), score the CVE when it lands with the [CVSS calculator](/tools/cvss-calculator), and keep up in [PlayCISO AI Labs](/ai-labs)._