PwnEscape (CVE-2026-99999): the KVM guest-to-host flaw and how to patch

PwnEscape (CVE-2026-99999) is a Linux kernel networking flaw that lets a KVM guest feed bad checksum metadata to the host, which can leak or corrupt host memory. It matters most if you run KVM hosts with guests you do not fully trust. Install your distribution's fixed kernel, reboot or live patch, and confirm with uname -r.

Fixes are arriving unevenly. As of 21 October, Debian, Amazon Linux and one Proxmox kernel series had fixed packages, while Ubuntu, Red Hat Enterprise Linux and SUSE still showed affected or pending on their own trackers.

What happened

PWN.AI Research, led by Paulos Yibelo, found the flaw while working on Vercel's Sandbox challenge. Their write-up says humans directed the research with an experimental harness that used GPT-5.6 Sol for source analysis, found the primitive in three days, and spent less than 700 dollars on API tokens. We cover the AI angle separately in how AI found PHP2Shell and PwnEscape.

Severity scores disagree

The Linux kernel CNA scores it 9.3 under CVSS 3.1, and Ubuntu shows the same 9.3 score while setting its own priority to Medium. Red Hat, Amazon Linux and SUSE all score it 8.8. The gap comes from one metric: the CNA assumes no privileges are required, while Red Hat and SUSE assume low privileges. AWS's bulletin assumes a privileged user inside the guest. SUSE also gives a CVSS 4.0 score of 9.3.

Lab versus production: sources do not agree

This is the part to read carefully. pwn.ai describes its results as coming from owned machines. In its lab, the team reports a repeatable 32-byte host memory disclosure per case, selected 64-byte host kernel writes, a bounded chain that ran a root helper on the host, and host crashes on disposable Linux 6.12 and 7.x hosts. The post says plainly that it is "not a claim of root command execution in any vendor's production environment", and that provider-specific telemetry is being held back until disclosure is cleared.

Two secondary sources go further. SmartScope and Secarma both say host memory disclosure was demonstrated against Vercel's production sandbox. pwn.ai's own post does not say that. The safest reading: a full escape was shown only in a lab; memory disclosure in a production setting has been reported by others but not stated by the researchers.

Is it being exploited?

We found no confirmed in-the-wild exploitation in the sources we reviewed, and we could not find the CVE in CISA's Known Exploited Vulnerabilities catalog. One oddity: Red Hat's CVE page says it "tracks this flaw as a KEV active-exploit case" without further detail. pwn.ai predicts working exploits for weaker configurations within weeks and for default configurations within a month, without giving evidence for that timeline. heise reports a similar expectation.

Who is affected

The vulnerable code is in the host's IPv4 output path, and it can be reached by any guest that hands the host packets with checksum offload metadata through virtio-net. AWS's bulletin describes affected systems as KVM hosts running unpatched kernels from 4.4 through 6.18.

The upstream commit's Fixes tags point at TUN and packet socket offload code, and pwn.ai says TUN and AF_PACKET cases without a VM were also discussed. So a host with untrusted local users but no VMs is not automatically out of scope. We found no statements on Google Cloud or Azure host infrastructure, and non-Linux hypervisors are outside the advisories we read; ask your vendor rather than assuming.

Patching the kernel inside your own guest does not protect you from a neighbour on the same host. The host kernel is the one that needs the fix.

How it works

Virtual network cards let a guest leave some checksum work to the host. The guest attaches metadata to each packet saying where the checksum starts and where to write it, and the host fills it in later.

The problem is timing. According to pwn.ai and the commit message, the host had already read and trusted the packet's IPv4 header before it completed that deferred checksum. If the guest pointed the checksum write at the header itself, the late write could change a field the host had already checked. When the host then split the packet into fragments, it worked from the altered header and copied bytes it should not have. heise reports the researchers call this a new class, a "deferred-metadata trust inversion": a time-of-check to time-of-use problem with no race needed.

The fix, written by Michael S. Tsirkin and reviewed by Willem de Bruijn, is commit 6785011f8b16, "ipv4: validate checksum_start before completing checksum". It adds a helper, ip_check_csum_start(), and calls it before checksum completion in the IPv4 fragmentation path, the bridge netfilter path, nfnetlink_queue, the CHECKSUM target and xfrm. The commit calls itself a defence in depth measure and says fuller validation at input is still to come. TuxCare expects a second upstream fix to follow. Plan for at least one more kernel update.

Distro fix status

Each row below was checked against the vendor's own tracker or advisory on 21 October 2026 unless noted. Distributions backport fixes, so compare against your vendor's package version, not the upstream number.

Upstream stable releases carrying the fix, per the kernel CVE announcement as reported by SmartScope: 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 and 7.2.11.

Caveats:

• For some Amazon Linux streams, SmartScope lists slightly different package versions from AWS's bulletin. We used the bulletin. Check the ALAS for your stream.
• SUSE's CVE page lists a Liberty Linux 10 build (6.12.0-211.67.1.el10_2, RHSA-2026:85321) as fixed, but Red Hat's text for that advisory, issued 19 October, does not list CVE-2026-99999. Treat RHEL 10 as unfixed until Red Hat says otherwise.
• We found no Rocky Linux errata for this CVE. Rocky 9 and 10 have a KernelCare live patch.

What to do now

1. Find every host that runs guests. List your KVM, Proxmox, OpenStack compute and Firecracker hosts, plus any host where untrusted users have a shell. Hosts running guests you do not control come first.
2. Check the running kernel on each one.

uname -r
# RHEL family, Amazon Linux, SUSE
rpm -q kernel kernel-default 2>/dev/null
# Debian and Ubuntu
dpkg -l 'linux-image-*' | grep '^ii'
# Proxmox
pveversion -v | grep proxmox-kernel

3. Compare with your vendor's fixed version from the table above, or its tracker if it changed after 21 October.
4. Install the fixed kernel when your vendor ships one.

# Debian / Proxmox
apt update && apt full-upgrade
# RHEL family / Amazon Linux 2023
dnf update 'kernel*'
# Amazon Linux 2
yum update kernel
# SUSE
zypper patch

5. Move guests off the host before rebooting (see the next section), or apply a live patch if you cannot reboot.
6. Reboot and verify. Installing a kernel package changes nothing until the host boots into it. Check that uname -r now matches the fixed version.

uname -r
# RHEL family: reports whether a reboot is still needed
needs-restarting -r
# Debian and Ubuntu
ls /var/run/reboot-required 2>/dev/null && echo "reboot still required"

7. If you use KernelCare, confirm the CVE is covered on the running kernel.

kcarectl --patch-info | grep 'CVE-2026-99999'

8. If you are a tenant, ask your provider which hosts are patched and when, and check whether your VMs restart automatically after a host reboot. heise makes the same suggestion.

Reboot or live patch

AWS's bulletin states: "There are no workarounds for this issue." Red Hat says no mitigation meets its criteria for stability and broad applicability. That leaves two real options: boot into a fixed kernel, or apply a live patch.

TuxCare reported on 19 October that its KernelCare live patch is in the production feed for AlmaLinux, CloudLinux, Oracle Linux, Rocky Linux 9 and 10, and RHEL 9. RHEL 10 was in the test feed, EL8 was in review, and Debian work had started. A live patch fixes the running kernel without a reboot and without moving guests. You still want the vendor kernel on disk so the next boot is fixed too.

TuxCare also lists interim measures for hosts that can do neither yet. On hosts with untrusted guests, turning off checksum offload on those guests' virtio-net interfaces (csum=off and guest_csum=off in QEMU, or the libvirt equivalent) closes the guest path at a throughput cost and needs a full guest restart. TuxCare says it has not tested this, and SmartScope advises against treating it as safe. Restricting /dev/kvm to the kvm group and setting user.max_user_namespaces to 0 narrow the local routes but break rootless containers and some browser sandboxes. Treat all of these as stopgaps.

Live migration to patch without downtime

If you have spare capacity, you can patch a cluster with no guest downtime: drain one host by live migrating its VMs to a patched host, patch and reboot the empty host, verify, and repeat. SmartScope suggests the same approach.

# libvirt: move one running guest to a patched host
virsh migrate --live --persistent GUEST qemu+ssh://PATCHED_HOST/system

# Proxmox: online migration of one VM to a patched node
qm migrate VMID PATCHED_NODE --online

# OpenStack: live migrate a server off a compute node
openstack server migrate --live-migration SERVER

Patch an empty host first so guests land somewhere safe, and do one host at a time to keep capacity. CPU models, shared storage and network names must match across hosts, and guests with passthrough devices usually need a maintenance window instead. Cycle, as quoted by SmartScope, recommends verifying in staging and then restarting production in batches.

What would have helped

Practices any team can use

• A live list of hypervisors and their kernels. Most teams can say which repos use a library within minutes. Fewer can say which hosts run guests and which kernel each one booted. A daily job that records uname -r and the installed kernel package per host turns step 1 above into a query.
• Reboot as a routine, not an event. Hosts that reboot on a schedule, with spare capacity to drain one at any time, have proven runbooks. Hosts with years of uptime are the ones that cannot be patched this week.
• Live patch where reboots are expensive. If you already subscribe to a live patch service, confirm which kernels it covers before you need it.
• Separate trust levels. Guests you do not control, such as customer workloads or code sandboxes, belong on hosts that are patched first and watched most closely.

Where Safeguard fits

To be direct: Safeguard does not cover this one. Our scanning looks at source repositories, container images and SBOM files. It does not inventory the kernels running on your hypervisors, it cannot tell you which hosts still need a reboot, and it does not patch or live patch host kernels. A container image does not ship the kernel it runs on, so scanning images will not flag PwnEscape on the host underneath. For this incident, your configuration management, your distribution's tracker and your live patch vendor are the right tools.

Here is where Safeguard can still save time this week:

• The rest of the queue. PwnEscape landed alongside PHP2Shell, which does live inside images and repos. safeguard scan --image NAME or safeguard scan --dir . matches what you ship against vulnerability databases, and the platform shows which projects contain a given component and version. Reachability analysis helps you order the work. Our guide to finding affected products fast with an SBOM walks through it.
• Writing the rollout. The Safeguard CLI's assistant can edit code and run commands with your approval. You can ask it to draft a drain, patch, reboot and verify script for your hosts and review each command before it runs. /permissions lets you choose Ask, Accept edits, Plan, Auto (the default) or Strict, and Strict or Ask make sense anywhere near production. The desktop and phone apps can send work to a computer running the CLI and approve each command, which helps when a reboot window falls outside office hours.
• Gates for what you build. Policies and gates evaluated in the platform stop known vulnerable components in images and repos from moving forward. They do not apply to host kernels.

None of this would have prevented PwnEscape. The fix is a host kernel update and a reboot or live patch, done by whoever runs the host. For the wider month, see October 2026 security incidents and what would have helped.

If you want to try the CLI for the parts it does cover, download it from safeguard.sh/download and see the CLI documentation.

Common mistakes

• Installing the kernel and not rebooting. The package manager reports success, the scanner sees the new package, and the host keeps running the old kernel. Always check uname -r.
• Patching guests instead of hosts. A tenant's own kernel update does nothing for the host.
• Comparing against upstream version numbers. Debian, RHEL and SUSE backport fixes. Use the vendor's package version.
• Treating checksum offload changes as a fix. They are untested stopgaps, per TuxCare and SmartScope.
• Reading "lab only" as "safe to wait". Exploit predictions are measured in weeks. Hosts with untrusted guests should not wait.
• Forgetting the second patch. The current commit is described as defence in depth, with more validation to come.

FAQ

What is PwnEscape?

PwnEscape is the name pwn.ai gave CVE-2026-99999, a Linux kernel flaw in IPv4 checksum handling. A guest VM can supply checksum metadata that makes the host kernel write into a packet header it has already checked, which can leak or corrupt host memory.

Is PwnEscape a KVM bug?

Not strictly. The flawed code is in the host's networking stack. KVM hosts are the main concern because guests reach it through virtio-net.

Has PwnEscape been exploited in the wild?

We found no confirmed in-the-wild exploitation as of 21 October 2026, and it was not in CISA's KEV catalog when we checked. Red Hat's page mentions tracking it as a KEV case without detail. Researchers expect working exploits within weeks.

Do I need to do anything if I run VMs on AWS?

AWS says Amazon EC2, AWS Lambda and AWS Fargate are not affected and need no customer action. If you run your own KVM or Firecracker hosts on AWS, you must patch and reboot those hosts yourself.

Can I fix PwnEscape without rebooting?

Yes, with a live patch, if your vendor or a live patch service covers your kernel. TuxCare's KernelCare covers several Enterprise Linux distributions. Otherwise, live migrate guests to a patched host, then reboot the empty one.

How do I know the fix is active?

Run uname -r and compare the result with your vendor's fixed version. On RHEL family systems, the needs-restarting tool reports whether a reboot is still pending. With KernelCare, check the patch info for the CVE.

Try it yourself

Watch the Safeguard CLI handle a real fix in a repo, asking before each command it runs.

Click through it at your own pace, or open it full screen.

See how a phone can approve or deny each command sent to a computer running the CLI.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• pwn.ai: PwnEscape, guest-to-host KVM escape (CVE-2026-99999)
• Upstream commit 6785011f8b16, ipv4: validate checksum_start before completing checksum
• heise online: PwnEscape, critical Linux kernel flaw allows VM escape
• AWS security bulletin 2026-137-AWS
• Amazon Linux security center: CVE-2026-99999
• Debian security tracker: CVE-2026-99999
• Ubuntu security: CVE-2026-99999
• Red Hat: CVE-2026-99999
• Red Hat: RHSA-2026:85321
• SUSE: CVE-2026-99999
• AlmaLinux: PwnEscape (CVE-2026-99999) patched kernels
• Proxmox VE security advisories, including PSA-2026-00068-1
• TuxCare: PwnEscape KVM guest escape
• SmartScope: CVE-2026-99999 PwnEscape affected versions and status
• Secarma: PwnEscape Linux kernel VM escape

Last reviewed: 21 October 2026. This is a developing story; check the linked advisories for the latest status.