A two-week, $1m bounty challenge run by Vercel has produced PwnEscape, a critical Linux kernel networking flaw that let code inside a virtual machine read memory from the host underneath it. The finding cost its researchers under $700 in AI tokens, and it raises real questions about what a cloud-wide bug is worth and how bounty programmes cope with hunters who now work at machine speed.
What happened
On 18 August 2026 Vercel opened a public HackerOne programme with one goal: break out of Vercel Sandbox, the microVM service it sells for running untrusted and AI-generated code. The window ran until 1 September, the total pool was up to $1m, and the most any single report could earn was $50,000. That top tier was reserved for a flaw letting an attacker read or modify another tenant’s data.
On day three, Paulos Yibelo of pwn.ai, working from an ordinary sandbox, filed what Vercel later called the programme’s most important report. The bug has since been assigned CVE-2026-99999, carries a CVSS score of 9.3, and was published under the name PwnEscape on 15 and 16 October, after a fix landed in the mainline Linux kernel on 14 October.
Vercel’s own results post, dated 14 October, puts the challenge in numbers: 1,285 reports in a fortnight, of which 877 were duplicates, 319 were not applicable and just 57 were valid. Triage produced one Critical, five High, nine Medium and 42 Low findings, plus 32 informative reports, and Vercel paid out $242,000 in total. PwnEscape was the only Critical. Neither Vercel nor the researcher has said what the PwnEscape report itself was paid.
The technical picture
The important detail is where the flaw sits. It is not in KVM, not in Firecracker and not in anything Vercel configured. It is in the host’s IPv4 networking code. According to the researcher’s write-up, guest-supplied checksum metadata could steer a deferred checksum write into an IPv4 header the kernel had previously checked. Altering the header length at that stage makes the fragmentation code copy bytes from beyond the packet into outgoing traffic.
The result, demonstrated against Vercel’s production sandboxes, was a repeatable leak of roughly 32 bytes of host memory per packet, for as long as the guest kept sending. In a lab built to match Vercel’s configuration, pwn.ai went further: two crafted packets crashed the host and every sandbox on it, and a bounded chain of selected kernel writes produced root on the host across four cold boots. The researchers are careful to say that the host takeover was shown only on machines they owned, and Vercel reports no evidence that any customer files, secrets or application data were read.
The fix, commit 6785011f8b16 from Red Hat’s Michael S. Tsirkin, adds a guard at five checksum completion points so the write cannot fall inside the IPv4 header; its author calls it defence in depth rather than a complete answer. Backports cover stable branches from 5.10 to 7.2, including 6.12.113 and 6.18.57. The attack vector is local: the attacker must already run code inside a guest, which is exactly what a sandbox customer does.
Why it matters for UK organisations
Vercel makes the wider point itself: most major clouds rely on the host Linux kernel to keep tenants apart, so this is shared-infrastructure risk, not one vendor’s problem. It says it worked with AWS and other partners on the fix, and pwn.ai credits it with alerting other affected hypervisor and sandbox providers.
For UK organisations, anyone running their own KVM estate, whether a hosting firm, an MSP, a university cluster or a private cloud, must patch host kernels themselves. Teams building AI agent platforms on microVMs are running exactly the threat model PwnEscape breaks. Buyers of sandboxed compute should ask providers, in writing, when their hosts took the fix.
There is also a disclosure lesson. Candidate patches were on the public netdev mailing list from 19 September, weeks before the CVE, and Vercel’s 14 October post says it was revealing the bug’s existence only because it had already been disclosed elsewhere in public. Cybernews reports that Adel Ka of Perplexity AI rediscovered the flaw quickly after a hint about VirtIO. Once a fix is visible upstream, capable teams with AI help can work backwards to the bug fast, and pwn.ai expects exploits for weaker configurations “to arrive in weeks”.
Expert view
In my experience, time-boxed challenges like this are the most honest form of bounty programme, because the vendor commits to a scope, a budget and a public write-up. Vercel did all three, and layered the crowd over internal testing and a four engineer-week white-box review from Trail of Bits. That layering is worth copying: an intern found a separate cross-tenant storage leak, and a public hunter found a snapshot trust flaw that Trail of Bits had also flagged.
The economics are harder to applaud. A flaw threatening tenant isolation across much of the cloud was found in three days for less than the price of a decent laptop, and its ceiling was $50,000 from one vendor. Cybernews describes a debate over that figure, and it is a fair one. Programmes that cap rewards by impact on their own platform will always underprice bugs in shared upstream code, and nobody else in the supply chain is paying.
The triage figures should give pause to anyone launching a programme. Roughly 68 per cent of reports were duplicates and a quarter were not applicable; Vercel credits the volume to hunters who “now hunt at AI speed”. AI tooling multiplies output, but the human effort of validating it does not shrink, and a programme without triage capacity will drown.
What to do now
- Patch host kernels first. Move KVM and Firecracker hosts to a fixed stable release or a distribution build that includes commit 6785011f8b16, then reboot. Distributions often backport without changing version numbers, so check the advisory, not just uname. Guest kernel updates do not fix the host. This maps to the Cyber Essentials security update management control.
- Ask your providers. If you consume sandboxed or virtualised compute, ask suppliers to confirm in writing when their hosts were patched for CVE-2026-99999.
- Limit blast radius. Follow Vercel’s own hardening: disable nested virtualisation where it is not needed and run each microVM under Firecracker’s jailer with minimal privileges. This supports secure configuration and access control.
- Treat guest data as hostile. Review any control plane that accepts values from inside a VM or container. Derive them server-side or sign them with keys the guest cannot reach.
- Size your bounty for triage, not just rewards. Budget for duplicates at AI volume, publish known-duplicate classes and require a working proof of concept, as Vercel did.
- Watch upstream fixes, not only CVE feeds. PwnEscape’s patches were public before its CVE. Track kernel stable releases for the components your hosts depend on.
Bottom line
PwnEscape shows a well-run bounty challenge doing its job: surfacing a critical, industry-wide kernel flaw, getting it fixed upstream and publishing the results. It also shows the strain on the model, with cheap AI-assisted discovery, single-vendor rewards and fixes visible before advisories. UK teams running virtualised workloads should patch hosts now and press providers for dates.
Sources
- Vercel: Findings from the $1M Vercel Sandbox challenge
- Vercel: $1 million hacker challenge for Vercel Sandbox
- pwn.ai: PwnEscape write-up
- The Hacker News: Critical PwnEscape Linux Kernel Vulnerability Lets Guest VMs Read Host Memory
- Cybernews: Critical Linux kernel vulnerability leads to full KVM escape
- Linux kernel: commit 6785011f8b16
