Security

CVE-2026-99999 (PwnEscape): What It Is and How to Fix It on Every Major Linux Distro

Ruby 13 min read

CVE-2026-99999 (PwnEscape) is a critical Linux kernel flaw that lets a VM guest attack its host. Here is what it is, who is at risk, and how to patch every major distro.

What is CVE-2026-99999?

CVE-2026-99999 is a vulnerability in the Linux kernel's IPv4 networking code. It was found by Paulos Yibelo of PWNAI Research during Vercel's $1 million sandbox security challenge and reported privately to kernel maintainers on 4 September 2026. The fix was written by Michael S. Tsirkin of Red Hat, accepted into the networking tree on 8 October, and merged into mainline Linux on 14 October. The CVE was published on 15 October 2026.

Despite the "KVM escape" nickname, the bug is not in KVM or in any specific hypervisor. It lives in the host operating system's network stack. That matters because it means any setup where a less-trusted guest can push network traffic through a vulnerable Linux host kernel may be exposed, including KVM, Firecracker, and other virtualization and sandbox platforms.

The vulnerable code dates back to Linux 2.6.27 (2008), with a related change in 2010. In practice, every kernel your distribution has shipped for roughly 18 years contains it.

How the bug works

You do not need to be a kernel developer to follow the idea.

Checksum offload. To save CPU time, a sender can hand the network stack a packet whose checksum is not finished yet, plus two pieces of metadata: where the checksum calculation starts and where the result should be written. This is a normal, widely used optimization, and virtual machines use it constantly through the virtio network device.

The missing check. The host kernel trusted that metadata without confirming it against the packet's actual IPv4 header. A guest could send metadata that points inside the IPv4 header.

The late rewrite. The kernel first reads and trusts the IPv4 header. Later, during fragmentation, it completes the pending checksum and writes the result. With bad metadata, that write lands on the header that was already parsed and approved. In the researcher's example, a single header byte changed so that a 20-byte header was suddenly treated as 60 bytes long.

The leak. The fragmentation code then copied 60 bytes of "header" when only 28 bytes of packet data really existed. The extra bytes came from the host's own memory and were sent back out in the packet as if they were IP options. That is a repeatable host memory leak, triggered from inside a guest.

From that starting point the researchers showed three outcomes:

  • Information disclosure: repeated leaks of host kernel memory. This was demonstrated against Vercel's production sandboxes.
  • Denial of service: the host can be crashed, taking down every VM on it.
  • Code execution: controlled writes into host kernel memory, chained into running a program as root on the host. This was shown only on the researchers' own KVM and Firecracker test machines, and the full technique has been withheld for a follow-up write-up.

The upstream developers describe the fix as a defense-in-depth measure. It adds a check that the checksum start cannot point inside the already-parsed IPv4 header, applied before checksum completion in five code paths. Broader validation of these packets at the point they enter the stack is still being worked on, so expect further kernel updates on this theme.

Who is affected (and why VPS customers should care)

The most exposed systems are hosts that run virtual machines for people you do not fully trust: public and private clouds, VPS providers, sandbox and CI platforms, and anything that executes customer code. On those machines, anyone who rents a VM can send the crafted packets, and a successful attack puts every other guest on the same host at risk.

But it is not only a hypervisor problem:

  • Red Hat's assessment says a local attacker can also reach the flaw, not just a guest VM.
  • CloudLinux notes the same code can be reached by unprivileged users on some configurations, for example through a user namespace creating a TAP device with the virtio header enabled. Their testing could not confirm exploitability on that path, but they treat it as plausible.
  • AlmaLinux recommends updating every system, whether or not it runs VMs.

If you are a VPS customer, you are the guest, not the host. You cannot fix the host kernel yourself. Updating the kernel inside your own VPS does not remove the vulnerable host path. The people who must patch are your provider. You should still update your own kernel, because of the local-attacker route, and you should ask your provider about their status (see the checklist in section 9).

Severity and exploitation status

  • CVSS 3.1 score: 9.3 (Critical) in the CVE record, vector AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. The vector is "Local" because the attacker must already run code in a guest or on the machine.
  • Red Hat rates it Important, 8.8, differing only on the privileges-required metric.
  • Ubuntu lists a Medium priority while showing the 9.3 CVSS score, and at last check had not yet finished evaluating its kernel packages.
  • Workarounds: Red Hat states no mitigation meets its criteria. The practical remedy is the patched kernel plus a reboot.
  • Exploit availability: the researchers published a detailed technical write-up of the bug and the memory leak, but not the full chain from leak to host control. They have said they expect working exploits against weaker configurations within weeks and against default configurations within about a month. Sources disagree on whether exploitation in the wild has been observed, so we are treating this as urgent rather than waiting for confirmation.

Our maintenance window: about 20 minutes offline

When the upstream fix and vendor kernels became available, we decided not to wait for a convenient moment. A guest-to-host escape that is known to be reachable from inside a VM, plus researcher warnings that exploits would follow within weeks, is the kind of flaw where waiting carries more risk than a short outage.

What we did:

  1. Reviewed the vendor advisories for our distribution and confirmed a patched kernel was available.
  2. Took our servers offline for a planned maintenance window of about 20 minutes on 19 October 2026, starting around 10:51 AM UTC.
  3. Installed the patched kernel packages.
  4. Rebooted into the new kernel. This is the step that causes the downtime, because a kernel update does not take effect until the machine restarts.
  5. Confirmed the running kernel version matched the patched release, checked that all services came back, and brought the site back online.

Why a reboot was unavoidable. Unless you use a live-patching service that has already shipped a fix for your kernel, there is no way to swap the running kernel in place. The Proxmox team put it plainly in their community forum: like every kernel update, you need to reboot to run the new kernel. If you run several hosts, the standard approach is to migrate workloads to another node before and after the reboot, which can reduce or eliminate visible downtime. We did not have that option for this window, so we accepted a short, announced outage instead.

Thank you to everyone who bore with us during the window. If you want to follow along on future security maintenance, we will always post the reason, the length, and the outcome.

How to fix it, distro by distro

The golden rule from the Linux kernel CVE team is to upgrade to a vendor-supported kernel that contains the fix rather than cherry-picking a single commit. Distributions often backport fixes without changing the upstream version number, so a version that looks old may be patched. Always compare against your vendor's advisory, not against upstream numbers alone.

For reference, the first upstream stable releases containing the fix, as reported by SOC Prime, are:

Branch

First fixed version

5.10

5.10.272

5.15

5.15.223

6.1

6.1.190

6.6

6.6.159

6.12

6.12.113

6.18

6.18.57

7.2

7.2.11

Mainline

7.3-rc7

If you build your own kernels, use these. Everyone else should follow their distribution below.

AlmaLinux 8, 9 and 10

AlmaLinux shipped patched kernels ahead of its upstream after its steering committee approved it, initially in the testing repository so the community could verify them before production release. The patched versions are:

Release

Patched kernel (or higher)

AlmaLinux 8

kernel-4.18.0-553.174.2.el8_10

AlmaLinux 9

kernel-5.14.0-687.57.2.el9_8

AlmaLinux 10

kernel-6.12.0-211.66.2.el10_2

AlmaLinux Kitten 10

Arrives in the next regular kernel update

If the fix has already moved to the production repositories, a normal update is enough:

sudo dnf update 'kernel*'
sudo reboot

If it is still only in testing, enable the testing repository just for this update, then turn it back off:

sudo dnf install -y almalinux-release-testing
sudo dnf update 'kernel*' --enablerepo=almalinux-testing
sudo reboot
# after the reboot, disable the testing repo again
sudo dnf config-manager --disable almalinux-testing

On a virtualization host, rebooting interrupts every guest, so migrate or shut down guests first.

RHEL, Rocky Linux, Oracle Linux and other RHEL-family systems

Red Hat lists RHEL 8, 9 and 10 (and its in-vehicle OS) as affected, rates the issue Important, and at last check said fixes were still being worked on, with no mitigation available. Rocky Linux and similar rebuilds normally follow Red Hat's release, so expect their fixes after it. What to do now:

# Check for the fix regularly
sudo dnf check-update 'kernel*'
# When a patched kernel appears
sudo dnf update 'kernel*'
sudo reboot

Follow the Red Hat CVE page and your rebuild's announcements. Because Red Hat's own errata trail upstream distributions here, hosts running untrusted guests should consider whether a different supported fix path is acceptable for their environment while they wait.

CloudLinux (7h, 8, 9, 10 and the LTS lines)

CloudLinux has published an advisory that sorts its products into four fix streams. At last check no fixed kernel or livepatch had shipped for most lines and the details were still being filled in, so check their page for current status.

  • CloudLinux 7h and 8 use CloudLinux's own kernel, which is rebuilt once the upstream fix lands. When a build reaches the testing channel: on CloudLinux 8 run yum update 'kernel*' --enablerepo=cloudlinux-updates-testing, and on 7h run yum update 'kernel*' --enablerepo=cl7h_beta, then reboot. After promotion to stable, yum update kernel and a reboot are enough.
  • CloudLinux 9 and 10 use the AlmaLinux kernel, so the fix arrives when AlmaLinux ships it. Once it is available, dnf update 'kernel*' and a reboot apply it.
  • CloudLinux 8 LTS and 9 LTS get kernels through TuxCare Endless Lifecycle Support, which backports fixes independently.
  • KernelCare livepatch can apply the fix without a reboot. It was rolling out for el9 first, with el8 and el10 in progress. On servers licensed through CloudLinux Network, livepatches apply automatically. Once published you can pull them manually with kcarectl --update.
  • CloudLinux for Ubuntu 22.04 runs the stock Ubuntu kernel, so the fix comes from Canonical through apt.

CloudLinux also notes that unprivileged user namespaces are on by default from CloudLinux 8 onward, so do not assume a newer server is protected on the local path.

Ubuntu (22.04, 24.04, 26.04 and others)

Canonical's tracker shows the kernel packages for all supported releases as "Needs evaluation" at last check, with no fixed package versions listed yet, and a Medium Ubuntu priority despite the 9.3 CVSS score. Ubuntu discourages cherry-picking individual patches. Once the security pocket has a fixed kernel:

sudo apt update
sudo apt full-upgrade
sudo reboot

Then confirm the running kernel changelog mentions the CVE:

uname -r
apt changelog linux-image-$(uname -r) | grep -i CVE-2026-99999

If you have Ubuntu Pro, Canonical Livepatch may deliver the fix without a reboot once published. Cloud-specific kernels (AWS, Azure, GCP, Oracle and others) are tracked as separate packages, so make sure you update the kernel flavor you actually run.

Debian

We did not retrieve a Debian status when preparing this guide. Check the Debian Security Tracker entry for CVE-2026-99999 for the fixed package version in your release (stable, oldstable or oldoldstable). When a fixed kernel is listed:

sudo apt update
sudo apt full-upgrade
sudo reboot

Proxmox VE

Proxmox staff confirmed the fix is in proxmox-kernel-7.0.14-24-pve (and the signed variant). It was released first to the no-subscription repository and has since reached the enterprise repository. Staff also stated that the 7.0.14 series is the only currently supported kernel series, and that older, end-of-life kernel series and product releases will not receive updates. If you are on one of those, upgrade to a supported release.

apt update
apt full-upgrade
reboot

On a cluster, migrate guests off each node before rebooting it and do a rolling upgrade. A forum user also reported that an NVIDIA driver failed to build against this new kernel, so test GPU passthrough or driver setups on one node first.

Partial mitigations if you cannot patch yet

These are not substitutes for the fix. CloudLinux describes them as partial and not yet tested against this specific bug, and Red Hat states no mitigation meets its standard for general use. Treat them as stopgaps on hosts you cannot patch immediately.

Hosts running untrusted VMs: stop offering checksum offload to guests. This is set per VM and needs a guest restart. It lowers guest network throughput because the guest loses some segmentation offloads.

# QEMU
-device virtio-net-pci,netdev=n0,csum=off,guest_csum=off
# libvirt (inside the <interface> element)
<driver><host csum='off'/><guest csum='off'/></driver>

Local path only: disable unprivileged user namespaces. This does nothing against a malicious VM guest. It also breaks rootless containers and some browser and Flatpak sandboxes.

sudo sysctl -w user.max_user_namespaces=0
echo "user.max_user_namespaces = 0" | sudo tee /etc/sysctl.d/90-no-userns.conf

To check whether unprivileged users can create namespaces on a server, run sysctl user.max_user_namespaces and try unshare -Urn as a normal user. If it fails, that local path is closed.

As a broader precaution, providers can limit what a compromised VM process could reach on the host. Vercel, for example, uses Firecracker jailer restrictions, disables nested virtualization, and limits host permissions for each microVM process. These do not fix the bug but can reduce the damage of an escape.

How to verify you are patched

  1. Reboot, then check the running kernel. Installing the package is not enough. The vulnerable kernel keeps running until you reboot.
    uname -r
rpm -q kernel        # RPM-based distros
  2. Compare to your vendor's advisory, not just the upstream version, because of backports.
  3. Check the changelog for the CVE, for example rpm -q --changelog kernel-$(uname -r) | grep CVE-2026-99999 on RPM systems or the apt changelog command above on Debian and Ubuntu.
  4. KernelCare users: run kcarectl --patch-info | grep CVE-2026-99999. CloudLinux warns that kcarectl --info returns nothing for this check even on a patched server, so use --patch-info.
  5. Check every host. In a fleet, verify the active kernel on each hypervisor or sandbox host rather than assuming the package install finished the job.
  6. If you suspect an escape, treat the whole host as potentially compromised, not just the guest. Preserve host memory and network telemetry where practical, and review kernel crash logs for anomalies tied to guest network activity.

Checklist for VPS customers

You cannot patch your provider's hypervisor, but you can protect yourself:

  • Ask your provider whether their hosts run a patched kernel, and when they patched. A good provider will tell you plainly.
  • Update your own VPS kernel and reboot, to close the local-attacker path.
  • Do not rely on guest updates alone. Only the host kernel update removes the guest-to-host path.
  • Minimize secrets on shared infrastructure until your provider confirms they are patched, and rotate credentials if you have any reason to suspect a compromise.
  • Plan for short maintenance windows. Reputable providers will reboot hosts for this. Short, announced downtime is a sign they took it seriously.
  • Watch your provider's status page and security announcements for confirmation.

Sources

Security advisories change quickly. This post reflects what vendors had published as of 19 October 2026. If you spot something out of date, tell us and we will update it.

Ruby