PwnEscape Kernel Flaw: Who Must Act on It

What happened, in dates

Vercel ran a public sandbox challenge in August 2026 with up to $1 million on offer for anyone who could break out of Vercel Sandbox. In a post on 14 October it said it had received 1,285 reports in two weeks, paid $242,000, and that the most severe finding was a zero-day in the upstream Linux kernel's networking stack [1].

The researcher, Paulos Yibelo of pwn.ai, published his own write-up on 15 October. It gives a timeline: first report to Vercel on 20 August, private report to the kernel security contact on 4 September, the fix accepted into the networking tree on 8 October, and merged into Linus Torvalds' mainline tree on 14 October [2]. The CVE record was published on 15 October as CVE-2026-99999 [4], and the same day Greg Kroah-Hartman released seven stable kernels containing the fix [5].

The CVE record rates it 9.3 out of 10, Critical, with a local attack vector, which means the attacker already has to be running code on the machine, here inside a guest VM [4][6]. It is not in CISA's known-exploited list and The Hacker News reports no sign of real-world use [6]. Those are the facts. The rest of this article separates what was demonstrated from what was only claimed.

How a checksum hint became a host-memory leak

This is the part most coverage skips, and it is the useful part. When Linux sends a packet it does not always compute the checksum straight away. It can mark the packet as CHECKSUM_PARTIAL, a note that says the checksum is still to be written, plus two numbers saying where to start and where to write. The researcher's description is that these values are not just labels: they authorise a later write into the packet's memory [2].

In a virtual machine, the guest supplies that metadata. The host's networking code validates the packet's IPv4 header, routes it, and possibly fragments it. Later, when the checksum is finally completed, the stored write position can point back into the IPv4 header itself. The header the kernel already checked is rewritten after the check, and the code after that trusts the new values [2]. The researcher turned that into a leak of about 32 bytes of host memory per packet the guest sent, which could repeat for as long as the guest kept sending [1][2].

Our reading, not a quote: it is a check-then-change bug. Nothing was parsed wrongly. Two parts of the kernel were allowed to trust different versions of the same packet. The fix adds one shared check that the checksum start does not fall inside the IPv4 header, applied before the checksum is completed at five places in the code [2][3]. Its author calls it a defence-in-depth measure and says a more complete validation where packets first enter the kernel still needs work [3][4].

One more detail worth knowing: the bug is not in KVM or in any hypervisor. It is in the host's own networking stack, which is why the researcher says the name 'KVM escape' describes the boundary that was crossed, not the file that contained the bug [2].

What was shown, and what was not

Shown against production: the memory leak. Vercel says it was demonstrated against Vercel production sandboxes [1]. Vercel also says no report showed anyone accessing customer data, and The Hacker News repeats that no customer files, secrets or application data were shown to be read [1][6].

Shown only in the researcher's own lab: crashing the host with two packets, which would take down every sandbox on that host, and running commands with full administrator rights on the host. Vercel says both were demonstrated on the researcher's own KVM and Firecracker machines set up to match Vercel Sandbox [1]. The researcher stresses this is not a claim of root access in any vendor's production environment [6].

Claimed by the researcher, not independently confirmed in what we read: that the full escape works in 'many other' hypervisor environments [2]. The write-up also notes that reviewers discussed paths using TUN or AF_PACKET sockets without a VM [2]. We found no demonstration of those, so treat them as open questions rather than known exposure.

Not proven, and easy to get wrong: that this is an internet-facing flaw. The record's attack vector is local [4], and The Hacker News says an outsider cannot exploit it by sending packets across the open internet [6].

Who has to act

If you run your own virtualisation hosts, KVM or Firecracker machines, self-hosted CI runners that use VMs, or a sandbox for customer code or AI agents: this is yours. Update the host kernel to a fixed release or your vendor's build and reboot into it. The Hacker News notes that updating only a guest's kernel does not fix the host, and that no separate workaround is given [6].

The first fixed stable releases listed in the CVE record are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 and 7.2.11 [4][5]. Distributions often backport a fix without changing the version number, so check your vendor's advisory and confirm the fix is in the kernel actually running, not only the number that uname prints [6].

If you build on a managed platform, cloud VMs, serverless or a hosted sandbox, the provider owns the host kernel. There is nothing for you to deploy. What you can do is read your provider's security notice. Vercel says it worked with AWS and other partners to prioritise a fix and keep its customers safe [1]. We could not verify what other providers have said, so check yours directly.

If you only run ordinary web servers and apps with no untrusted guests, the practical risk is low, because the attacker needs code running in the right place first [4][6]. It is still a critical kernel fix in a routine stable release, so it belongs in your normal patch cycle.

What it means if you build multi-tenant software

The more transferable lessons came from Vercel's own review, which included four engineer-weeks of source review by Trail of Bits. They gave three recommendations that Vercel says it implemented [1]. First, find and remove all trust in the guest: values returned by software running inside the sandbox are tenant input, so anything that crosses the boundary should be derived server-side or signed with a key the guest cannot reach. Second, one policy and one decider: Vercel's network policy was parsed independently by several subsystems that did not always agree, so it now uses one routine per data type and one component per decision. Third, assume the next zero-day, which means limiting the damage with up-to-date host kernels, no nested virtualisation and Firecracker's jailer.

Vercel's example of the first lesson is instructive. A snapshot's storage location was reported by software inside the guest and the host believed it. A researcher who owned two accounts used that to swap the contents of two snapshots between them. Vercel notes the attack needed a random 96-bit identifier it never exposes, and says the fix binds every snapshot object to the project that created it [1].

For a SaaS team the translation is ours, not Vercel's: any value that comes back from tenant-controlled code, a browser, a plugin or an AI agent's tool call is untrusted input, including identifiers and storage paths. Bind objects to the tenant on the server and do not rely on an ID staying secret. If your product runs customer code or agent actions, keep long-lived secrets out of the environment where that code runs and scope each credential narrowly.

What to expect next (prediction)

Prediction, not fact: expect more disclosures at the boundary between guests and the host kernel. The reasons are in the sources. The researcher says his team found the bug in three days with an AI-assisted research system for under $700 in API tokens, a figure we could not verify independently [2][6]. Vercel says the volume of reports was only possible because researchers now hunt at AI speed [1].

If that holds, the gap between a bug existing and someone finding it gets shorter, and patch cadence matters more than it used to. For anyone running their own hosts, that argues for kernel updates that are routine and rehearsed rather than a quarterly project.

Frequently asked questions

The short version

If you run your own VM hosts or sandboxes, patch the host kernel and reboot. If you use a managed platform, read your provider's notice and carry on. Either way, take the design lesson: nothing that comes back from tenant-controlled code should be trusted, and isolation depends on the whole host stack, not only the hypervisor.

If your product runs customer code or agent actions and you want a second pair of eyes on how it is built, our custom SaaS development process guide and services page explain how we scope that kind of work.