A critical Linux kernel vulnerability was discovered on the 15th of October. PwnEscape (CVE-2026-99999) allows code that is running inside of a virtual machine to read the host server’s memory and potentially take complete control over the entire host.
VPSBG's response
As a cloud hosting provider, we at VPSBG are aware of the PwnEscape vulnerability (CVE-2026-99999) and have been tracking it closely since it was first reported. Our security team has found no evidence that any VPSBG servers have been affected.
Given that the fix requires a host reboot, we will be rolling out patches in the next few days which may result in about 5-10 minutes of unscheduled downtime due to the restart.
We also highly recommend you update your Linux OS with the latest kernel and reboot to apply the changes as some container-based workloads (or nested virtualization) is also affected.
What is PwnEscape?
PwnEscape is a guest-to-host escape flaw that sits in the host kernel’s IPv4 networking code, affecting multiple different virtualization platforms like KVM and Firecracker.
CVE | CVE-2026-99999 |
|---|---|
Nickname | PwnEscape |
Severity | Critical |
Component | Linux kernel IPv4 networking stack (checksum offload handling) |
Attack type | Guest VM escape and host memory disclosure |
Vulnerable since | Linux 2.6.27 (2008) |
Discovered by | Paulos Yibelo, PWNAI Research |
Fix | Upstream commit 6785011f8b16, merged 14 October 2026 |
Exploited in the wild? | No confirmed exploitation reported |
How does it work?
PwnEscape abuses checksum offload, which is a performance feature that allows a virtual machine to hand over checksum calculation to the host with the host kernel trusting the instructions on where the checksum needs to be written without checking against the packet’s IPv4 header. Here’s the breakdown:
A VM sends network packets through its virtio network device, leaving the checksum incomplete and adding metadata that specifies where the host should write it.
The host kernel reads and validates the packet's IPv4 header, then proceeds with the execution.
The host's checksum helper (skb_checksum_help()) writes the checksum where the metadata points to.
This overwrites the changes to the header-length field from 5 to 15, so a 20-byte header gets treated as 60 bytes inside a 28-byte packet.
When the host processes the packet further (like during IP fragmentation), it reads past the real packet into neighbouring kernel memory and sends that data back to the attacker.
Overall, the hypervisor’s kernel validates the header only once, then lets untrusted metadata modify it while trusting the original result, meaning that no special privileges, user interaction or complex setup are needed from an attacker besides controlling a virtual machine.
What can an attacker do with this vulnerability?
If the attacker gets such access, they can potentially leak host kernel memory or crash the host, meaning that the whole node with all other VMs would go down. Additionally, they can also write to host kernel memory and chain it into running code as root on the host.
How was PwnEscape discovered?
Here’s the full disclosure timeline:
Date (2026) | Event |
|---|---|
20 August | Initial host-memory disclosure submitted to Vercel's challenge |
4 September | Root cause privately reported to Linux kernel security and networking maintainers |
8 October | Fix accepted by kernel networking maintainers |
14 October | Fix merged into the mainline Linux kernel |
15 October | Linux kernel CVE team publicly announces CVE-2026-99999 |
16 October | Distributions and cloud providers begin publishing advisories and patched kernels |
What’s the fix?
The fix for this vulnerability is to patch the host’s kernel and apply by rebooting. The upstream patch, ipv4: validate checksum_start before completing checksum (commit 6785011f8b16), was written by Michael S. Tsirkin of Red Hat. The check performed here validates the checksum location before the host’s kernel writes it, meaning that the checksum can no longer land on the IPv4 header, causing all malformed packets to be dropped.
-thumb16x9.webp)