CVE-2026-99999 — PwnEscape: detection and mitigation

Practical guide in Spanish to determine whether a Linux server is exposed to CVE-2026-99999 ("PwnEscape") and how to mitigate it. Includes a script that checks the machine and gives a verdict with the reason.

📋 Summary

Field	Value
CVE	CVE-2026-99999
Name	PwnEscape
Component	Linux kernel, IPv4 checksum processing (`skb_checksum_help()`)
Severity	CVSS 3.1 9.3 (Critical) — `AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H`
Impact	A malicious VM can read host memory, crash it, and, in a lab, take control with root
Vector	Local: the attacker needs to execute code inside a VM
Discovered by	Paulos Yibelo (pwn.ai), during Vercel's Sandbox Challenge
Published	October 15, 2026
Upstream fix	Commit `6785011f8b16` (Michael S. Tsirkin, Red Hat)
Active exploitation	Not reported · Not in CISA's KEV catalog

🧠 What is it? (explained simply)

Think of an apartment building:

The building is the physical server, the host.
Each apartment is a virtual machine (VM).
PwnEscape is a flaw in the building's walls: from an apartment, a malicious tenant can spy on or break into the building's administration.

┌──────────────────────────────────────┐
│  HOST (servidor físico + hipervisor) │  ← aquí está la falla
│  Linux con KVM / QEMU / Firecracker  │
│                                      │
│   ┌─────────┐ ┌─────────┐ ┌────────┐ │
│   │  VM  A  │ │  VM  B  │ │  VM  C │ │
│   │         │ │(atacante)│ │        │ │
│   └─────────┘ └─────────┘ └────────┘ │
└──────────────────────────────────────┘

The flaw is in the host, not in the VMs. That's why:

✅ If your server is a VPS or a VM (DigitalOcean, AWS, Hetzner, Proxmox, etc.), you are not the target. The one who must patch is your provider or whoever administers the host.
⚠️ If your server hosts VMs (Proxmox, KVM/libvirt, OpenStack, Firecracker), you are the target, especially if you run third-party VMs or untrusted code.

🔬 How does it work? (technical level)

Linux allows network packets to carry metadata indicating where a checksum starts and where its result is written. It is a legitimate optimization for checksum offloading.

The problem is the order of operations:

The kernel receives a packet from the VM with a normal IPv4 header (IHL = 20 bytes) and validates it.
Then, a deferred checksum operation, controlled by the metadata sent by the VM, rewrites that same already-validated header and changes it to IHL = 60 bytes.
The fragmentation logic trusts the new value and copies more data than the packet actually has.
Those extra bytes are host memory (32 bytes per packet in the test), and the attack can be repeated.

The fix validates that the start of the checksum cannot point inside an already-processed IPv4 header. It is applied in five affected network paths.

The vulnerable code has existed since kernel 2.6.27 (2008).

📦 Fixed versions

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

⚠️ Ubuntu, RHEL/Rocky/Alma, SUSE and Proxmox use their own numbering (for example 5.15.0-125-generic or 5.14.0-503.el9). On those distros the version says nothing by itself: you have to check the distro's security advisory or the kernel changelog.

Branches outside this list (6.8, 6.19, 7.0, 7.1…) no longer have upstream support and did not receive the fix.

🔍 Am I affected?

Option A — Automatic script (recommended)

curl -O https://raw.githubusercontent.com/alvaroguzmancode/CVE-2026-99999/refs/heads/main/check-pwnescape.sh
sudo bash check-pwnescape.sh

El script revisa tres cosas:

Rol del equipo: si es una VM, si hospeda VMs o si puede hospedarlas pero hoy no lo hace.
Parche: busca el CVE en el changelog del kernel y compara contra las versiones corregidas.
Reinicio pendiente: si hay un kernel nuevo instalado que todavía no está activo.

Ejemplo de salida en un VPS:

== VEREDICTO ==
  Rol:    Este equipo ES una máquina virtual; no hospeda otras VMs.
  Kernel: VULNERABLE — la versión del kernel es anterior a la corregida.

  NO EXPUESTO DIRECTAMENTE.
  La falla solo se explota desde una VM hacia el servidor que la hospeda.
  Este equipo no hospeda VMs, así que no hay a quién atacar desde aquí.

  Ojo: el que SÍ debe estar parchado es el host que aloja esta VM
  (tu proveedor de nube o tu servidor Proxmox/KVM). Confírmalo con ellos.

Exit code	Meaning
`0`	Not vulnerable or not exposed
`1`	Vulnerable
`2`	Could not be confirmed, needs manual review

Option B — Manual review

1. Am I a VM or a host?

systemd-detect-virt                     # "kvm", "xen", etc. = eres una VM; "none" = físico
pgrep -a qemu-ga                        # si aparece, eres una VM (QEMU Guest Agent)
lsmod | grep -E 'kvm|vhost'             # módulos de virtualización cargados
cat /sys/module/kvm_intel/refcnt 2>/dev/null || cat /sys/module/kvm_amd/refcnt   # >0 = hay VMs usando KVM
virsh list --all 2>/dev/null            # VMs de libvirt
pgrep -a '^(qemu-system|firecracker)'   # VMs / microVMs corriendo

2. Does my kernel have the patch?

uname -r

# Debian / Ubuntu
zgrep -i "CVE-2026-99999" /usr/share/doc/linux-image-$(uname -r)/changelog.Debian.gz

# RHEL / Rocky / Alma / Fedora
rpm -q --changelog kernel-core-$(uname -r) | grep -i "CVE-2026-99999"

3. Is a restart missing?

[ -f /var/run/reboot-required ] && echo "Falta reiniciar"   # Debian / Ubuntu
needs-restarting -r                                          # RHEL

🛡️ Mitigation

1. Update the host kernel (real solution)

# Debian / Ubuntu / Proxmox
sudo apt update && sudo apt full-upgrade

# RHEL / Rocky / Alma / Fedora
sudo dnf update kernel

Kernel maintainers recommend installing the full stable release of your distro, not applying the standalone commit.

2. Reboot and verify

sudo reboot
# después:
uname -r
sudo bash check-pwnescape.sh

Installing the package is not enough: the new kernel only takes effect after rebooting. In clusters, verify every hypervisor.

3. Patching only the VMs is useless

Updating the kernel inside the VMs does not eliminate the risk, because the flaw is in the host. If you are a VPS customer, confirm with your provider that they have already patched their hosts.

4. Unload KVM if you don't use it

If the machine has KVM loaded but does not host VMs, you can reduce the attack surface:

sudo modprobe -r kvm_intel kvm_amd kvm 2>/dev/null
echo -e "blacklist kvm_intel\nblacklist kvm_amd\nblacklist kvm" | sudo tee /etc/modprobe.d/no-kvm.conf

5. Defense in depth (while you patch)

These measures do not fix the flaw, but they limit what an attacker who escapes from a VM could achieve:

Disable nested virtualization if you do not need it.
Use jailer in Firecracker or equivalent sandboxing (seccomp, cgroups, namespaces).
Run each VM process with the minimum possible privileges on the host.
Prioritize patching on hosts that run untrusted code: CI/CD, sandboxes, customer VMs, or AI agents.

CVE-2026-99999

Most Popular