TL;DR: A critical flaw in the Linux kernel, named PwnEscape, let an attacker inside a virtual machine read memory from the host underneath it and crash the whole box. The fix reached the mainline kernel in mid-October. If you run untrusted VMs, patch the host and reboot now.
Introduction
A bug sat quietly in the Linux kernel since 2008. Last week it woke up. A researcher showed it could let an attacker escape a virtual machine and reach the host that runs it. The fix only just landed.
What Happened?
A researcher found a hole in how the Linux kernel handles network packets. The flaw, named PwnEscape and tracked as CVE-2026-99999, lets code inside a guest VM break out of isolation and read the host’s memory. It scored 9.3 out of 10. The weak spot sits in the kernel’s checksum offload path. Crafted packet data points a delayed write into an IPv4 header the kernel already trusted. The host then hands back about 32 bytes of its own memory with every packet that leaves. Two packets were enough to crash a host in testing.
It turned up during a cloud platform’s two-week challenge that dared researchers to break out of its sandboxes. The prize pool reached $1 million, and this was the only critical bug anyone submitted. Here is the part that should make defenders sit up. The researcher did not grind for months. An AI-assisted offensive setup surfaced it in about three days, for less than $700 in tokens.
What’s the Impact?
This one hits shared infrastructure hardest. Any host running untrusted VMs on an unpatched kernel is exposed, from VPS fleets to the sandboxes behind AI agents. One tenant could read or crash the machine another tenant shares. No real attacks have surfaced yet, and it is not on CISA’s exploited list.
The Fix
The patch reached the mainline kernel in mid-October. It adds a check so a packet’s checksum data cannot point into the IPv4 header before the kernel acts on it. The author calls it a defense-in-depth step and says deeper validation still needs work. Updating the guest does nothing. The host is what you patch.
How to Avoid This
- Patch the host kernel, then reboot
- Guest-only patching does nothing
- Multi-tenant hosts go first
- Turn off nested virtualization where you can
- Confirm the running kernel carries the fix
The patch is public. Finding every host that needs it is the real work.
A fix this size won’t protect you until it reaches every host running untrusted VMs. The hard part is knowing which machines are exposed, proving the fix took hold, and getting there before someone turns a public write-up into a working exploit.
- Find every host still on a vulnerable kernel, across cloud and on-prem
- Rank the risk by real exposure, so multi-tenant hosts move to the front
- Run the patch and reboot behind your own approval gates
- Retest the host to confirm the escape path is closed
- Keep watching for the kernel panics and odd fragmentation that hint at probing