CVE-2026-99999 (PwnEscape): Linux Kernel Flaw Lets a Guest VM Read Host Memory

A flaw in the Linux kernel's networking code lets code running inside a virtual machine read memory from the host it runs on. It is tracked as CVE-2026-99999, carries a published CVSS score of 9.3 (Critical), and researchers have nicknamed it PwnEscape. Paulos Yibelo of the security firm pwn.ai found it during Vercel's sandbox challenge and reported it privately, and the Linux kernel fix was published on October 15, 2026.

No exploitation in the wild has been reported, and CISA has not added it to the Known Exploited Vulnerabilities (KEV) catalog. The reason to read on is the combination of a very old code path, a bug that crosses the line between guest and host, and a discovery process that leaned heavily on AI tooling.

How PwnEscape Works

The kernel's own description is short: if a packet with bad checksum metadata reaches the IPv4 stack, skb_checksum_help can corrupt the network header and cause what the maintainers call a bunch of mischief. The fix title is "ipv4: validate checksum_start before completing checksum."

Per the write-ups, Linux can defer a checksum calculation, and the packet's metadata says where the checksum starts and where to write the result. A guest can influence that metadata. In the case Cybersecurity News describes, a header that first looks like a standard 20-byte IPv4 header can be read as 60 bytes after the deferred write. The fragmentation code then treats bytes beyond the valid packet data as header and copies them into an outgoing packet, which exposes about 32 bytes of host memory.

The researcher showed three results from that one flaw. The first is a host memory leak, which the guest can repeat for as long as it keeps sending packets, and Vercel confirmed it against its live production sandboxes. The second is a host crash, where two crafted packets were enough to take down a host and every sandbox on it. The third is root-level control of the host. The last two were seen only on the researcher's own KVM and Firecracker machines, set up to match Vercel's configuration. Yibelo stressed that this is a lab result and not a claim of root command execution in any vendor's production environment.

He also said the work took three days and used an AI-assisted research system, an internal harness called Omega-Pwn that combines pwn.ai's own tooling with elements of SingularityNET's OmegaClaw architecture, with GPT-5.6 Sol as the main reasoning engine. THN reports the model usage cost under $700 in API tokens. These figures come from pwn.ai's own account to THN.

Who Is Affected

The flaw lives in the host's Linux kernel networking code, not in a specific hypervisor or in one company's setup. The attacker has to be able to run code inside a guest VM, so this is a local attack vector and outsiders cannot exploit it over the internet. That puts cloud providers, sandbox platforms, hosting companies, and anyone who runs other people's code in VMs at the front of the line.

Vercel's case shows the shape of the risk. Each customer runs in its own Firecracker microVM with its own guest kernel on bare-metal Amazon EC2 hosts, and the flaw sits in the host kernel those microVMs share. Vercel says no report showed anyone reading a customer's files, secrets, or application data.

The maintainers backported the fix to the stable branches. The first fixed versions are 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57, and 7.2.11, and the 7.3 development series has it from 7.3-rc7. VulnTracker's version list for this CVE begins at Linux 2.6.27, which points to a long-lived code path. Distributions often add such fixes without changing the version number, so the vendor advisory is the reliable check.

Cybersecurity News also warns that two other reports, a KVM escape confirmed by Vercel and a Linux vhost flaw with a public proof of concept, are separate issues and should not be assumed fixed by this patch.

A 9.3 With a Local Vector: Who Should Care

The score and the exposure point in different directions. A 9.3 is consistent with a local attack vector and a changed scope, which fits a flaw whose impact crosses from the guest into the host. For a company that runs only its own workloads on its own hosts, the attacker is already inside, and the practical risk is lower than the number suggests. For any platform that shares one host kernel among tenants who do not trust each other, the same bug turns a low-privilege foothold into a view of other tenants' memory.

That split is why this entry works as a triage example. KEV status and exploitation reports are absent, so nothing here forces an emergency change window. The question to ask is whether your hosts run code from people you do not control, such as customer sandboxes, CI runners, or shared VPS nodes. If they do, this is a patch-and-reboot item. If they do not, it can go through the normal kernel update cycle.

Two details raise the stakes slightly. The kernel fix is deliberately partial. Its author calls it a defence in depth measure, and the CVE text says a more complete validation at packet input is forthcoming but needs more work. The flaw was also found in about three days with an AI-assisted pipeline. Vercel's challenge drew 1,285 reports and paid $242,000, with a top reward of $50,000 per THN, and this flaw was the only critical finding. Other kernel bugs may well surface the same way.

Reading It on VulnTracker

The page shows CVE-2026-99999 as published on October 15, 2026, with a CVSS 3.1 score of 9.3 (Critical) from the Linux kernel's own CNA. There is no Actively Exploited banner and no KEV dates, which matches the reporting, and the status reads Received because NVD has not analyzed the entry yet, so the structured platform list is empty.

The Affected Products list shows Linux with two version entries: 2.6.27 and a commit hash, which mark where the flaw entered the code. For the versions that matter in practice, use the fixed releases listed above, since the record's own range will not tell you whether your distribution has backported the patch. The References section carries eleven links, eight of them kernel stable commits, plus the pwn.ai write-up, Vercel's challenge report, and the oss-security announcement on Openwall.

What to Do This Week

First decide whether your hosts run guests you do not control. If they do, put this ahead of routine kernel work.

• Update the host kernel to a fixed release (5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57, 7.2.11, or 7.3-rc7 and later), or to your distribution's build that carries the fix, and reboot. Updating only the guest kernel does not fix the host, and the sources describe no separate workaround.
• Read your distribution's security advisory and confirm that the running kernel has the fix, because a backport may not change the version number.
• If you rent capacity from a cloud or sandbox provider, ask whether it has patched its hosts. That fix sits on their side, and you cannot apply it from inside a VM.
• Keep the hardening Vercel describes: current host kernels, nested virtualization turned off, and each microVM confined under Firecracker's jailer. These steps narrow the impact and do not fix the flaw.
• Do not mix tenants of different trust on one host where you can avoid it, and treat unexplained host crashes triggered by guest traffic as something to investigate, since two crafted packets were enough to bring a host down in the lab.
• Watch the kernel mailing lists for the follow-up. The maintainers describe the current fix as partial and say a fuller input check is still to come.

PwnEscape matters most to anyone who shares a kernel with strangers. Patch those hosts first, confirm the fix with your distribution rather than the version string, and keep the rest of the fleet on its normal schedule. Track the Linux kernel on VulnTracker, and when the maintainers ship the fuller input check you will see it as soon as the entry changes.

References

Vendor: Linux kernel fix commit, oss-security announcement, pwn.ai write-up. NVD: CVE-2026-99999. Analysis: THN, Cybersecurity News, Vercel.