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

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, 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 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:

1. 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.
2. The IPv4 header is validated — at this instant IHL is the normal 0x45 (version 4, header length 5 words = 20 bytes).
3. 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.
4. 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.
5. 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

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, 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 →.

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) — technical write-up at pwn.ai/blog/pwnescape. Independent primary source: Vercel, “Findings from the $1M 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. Compare isolation designs with the hypervisor comparison, harden your hosts with the KVM hardening checklist, score the CVE when it lands with the CVSS calculator, and keep up in PlayCISO AI Labs.