PwnEscape: a Linux kernel bug that lets one tenant peek at another
A critical flaw in the Linux networking stack, demonstrated against live Vercel sandboxes, breaks the wall between a guest machine and the host it shares with strangers.
Key points
- A Linux kernel flaw nicknamed PwnEscape, tracked as CVE-2026-99999, lets code inside a virtual machine read memory belonging to the physical host, which in a shared cloud means reading data belonging to other customers.
- A researcher called Paulos demonstrated the leak against Vercel's live sandbox product, and Vercel confirmed the finding.
- The bug lives in the Linux kernel's IPv4 networking code, specifically a function called
skb_checksum_help, which can be tricked by a packet with bad checksum data into corrupting the network header. - A patch landed on 15 October 2026 as a stop-gap; kernel maintainers say a fuller validation at the input stage is still being written.
- No identity control, from multi-factor authentication to session binding, would have blocked this; it sits below all of that.
A Linux kernel bug disclosed this week does something cloud providers spend a lot of money pretending is impossible: it lets a program running inside one virtual machine read bits of memory belonging to the real server underneath. A virtual machine is a software-simulated computer sharing a physical server with other customers. On a public cloud, that shared memory can hold anything the neighbours are doing.
The flaw is CVE-2026-99999, nicknamed PwnEscape. Paulos, the researcher who found it, demonstrated it against Vercel's sandbox product, which runs customer code in short-lived virtual machines. Vercel confirmed it worked. Yesterday we reported on Vghost, a different guest-to-host kernel bug that survived almost a decade of kernel releases; PwnEscape shows the category isn't thinning out.
What actually goes wrong?
IPv4 is the packet format most of the internet still runs on. When Linux is asked to finish calculating a checksum, a small number used to verify a packet arrived intact, it trusts a pointer inside the packet's metadata without confirming the pointer is sane. Feed it deliberately bad metadata and skb_checksum_help writes into memory it shouldn't touch.
From inside a guest, that's enough to corrupt data the host kernel holds and, handled carefully, to read it back. The maintainers' own commit note says such packets should never have reached that code path. A stricter input check is still being written; what landed on 15 October 2026 is a defence-in-depth guard while that work continues.
Who is actually exposed?
Anyone running untrusted code on a shared Linux host. That covers the serverless industry, CI runners, free-tier app platforms and multi-tenant Kubernetes clusters. It's in the kernel, not in any one provider's wiring, so it doesn't matter which cloud you picked.
| Detail | Value |
|---|---|
| CVE | CVE-2026-99999 |
| Component | Linux kernel, IPv4 checksum path |
| Fix published | 15 October 2026 |
| Demonstrated against | Vercel sandboxes |
Honest read: this matters less because of what Paulos did to Vercel and more because of what any competent attacker can now do to a CI runner rented for a few dollars. The demo was polite; copycats won't be. Watch for kernel updates from your cloud this week, and if a provider stays quiet about which kernel version they're running, that silence is the story.
Should you worry?
If you manage your own Linux servers, apply the kernel update your distribution ships this week. For everyone paying someone else to run the servers, check whether your provider has posted confirmation that their fleet is patched. This isn't a password problem, so rotating credentials won't help. The fix has to happen in the kernel underneath you.
