PwnEscape (CVE-2026-99999): la falla del kernel de Linux que puede permitir escapar de una máquina virtual

En octubre de 2026 se hizo pública CVE-2026-99999, apodada PwnEscape, una vulnerabilidad en la pila de red IPv4 del kernel de Linux que, según sus descubridores, puede permitir que una máquina virtual invitada afecte al servidor que la aloja.

A pesar del nombre, no es un fallo de KVM ni del hipervisor. El problema está en el código de red del kernel del host: un invitado puede enviar paquetes con metadatos de checksum manipulados y el kernel termina escribiendo sobre una cabecera IPv4 que ya había leído y dado por buena.

La corrección ya existe en el kernel principal, pero el estado de los parches varía mucho según la distribución. Además, las fuentes publicadas no coinciden en todo, así que conviene separar lo confirmado de lo que no lo está.

Resumen rápido

• Identificador: CVE-2026-99999, apodado PwnEscape.
• Componente: la pila de red IPv4 del kernel de Linux (función skb_checksum_help()).
• Causa: los metadatos de checksum no se validan antes de completar el checksum, lo que permite una escritura fuera de límites (CWE-787).
• Escenario principal: un invitado de virtualización (por ejemplo, con virtio-net) que no es de confianza.
• Impacto descrito por los investigadores: filtración de memoria del kernel, caída del host y, en un laboratorio propio, ejecución de código como root en el host.
• Severidad: 8.8 (Importante) según Red Hat y 9.3 (Crítica) según el registro CVE.org.
• Explotación: las fuentes se contradicen (ver más abajo).
• Corrección completa: actualizar el kernel y reiniciar.
• No existe una mitigación oficial completa: las alternativas son parciales.

¿Qué es PwnEscape?

PwnEscape es el nombre con el que sus descubridores, el equipo PWNAI Research, bautizaron esta vulnerabilidad. El fallo está en cómo el kernel de Linux procesa ciertos metadatos de checksum que llegan junto con un paquete de red.

En una máquina virtual, el invitado puede indicar al host dónde debe escribirse el checksum de un paquete. Si ese dato no se valida contra la cabecera IPv4, el kernel puede terminar escribiendo sobre bytes de la cabecera que ya habían sido interpretados, lo que corrompe el paquete y memoria cercana.

El parche oficial añade una comprobación (ip_check_csum_start()) antes de completar el checksum, para asegurar que el punto de inicio no cae dentro de la cabecera IPv4. Los propios autores y el rastreador de Debian lo describen como una defensa en profundidad: aún queda pendiente una validación más completa de la entrada.

¿Qué impacto puede tener?

Los investigadores describen tres resultados en sus equipos de prueba:

• Filtración de 32 bytes de memoria del kernel del host por cada caso de prueba.
• Caída del host, probada en equipos de laboratorio con Linux 6.12 y 7.x.
• Ejecución de código como root en el host, en una cadena de laboratorio sobre KVM, repetida en cuatro arranques en frío.

Es importante tener presente el contexto: los autores indican que no lo demostraron en el entorno de producción de ningún proveedor, y otro proveedor (CloudLinux) señala que no ha podido reproducir la cadena completa.

¿Quién está expuesto?

Sobre la ruta local: CloudLinux la considera plausible por el código, pero no pudo confirmarla en sus pruebas. Red Hat indica que un atacante local también podría activar el fallo, y la publicación de los investigadores menciona escenarios con TUN y AF_PACKET que no necesitan una VM.

Severidad y estado de explotación: lo que no cuadra

Las fuentes consultadas no coinciden en dos puntos.

Con esta incertidumbre, lo prudente es tratarla como prioridad alta en cualquier host que ejecute VMs de terceros, sin esperar a que se aclare la discrepancia.

Estado de los parches

Datos publicados hasta el 16 de octubre de 2026 en las fuentes consultadas. Verifica siempre el aviso actual de tu distribución.

En el kernel principal, la corrección es el commit 6785011f8b16 («ipv4: validate checksum_start before completing checksum»), aceptado el 14 de octubre de 2026.

¿Cómo saber si estoy afectado?

1. Revisar el kernel en ejecución

bash
uname -r
uname -v

En Debian, uname -v muestra la versión del paquete del kernel (por ejemplo, Debian 6.1.190-1). Compárala con la tabla anterior.

En sistemas tipo RHEL:

bash
rpm -q kernel

2. Comprobar si el servidor ejecuta máquinas virtuales

bash
lsmod | grep -E 'kvm|vhost'

Si el host ejecuta VMs de terceros, la prioridad es máxima.

3. Revisar los user namespaces

bash
sysctl user.max_user_namespaces

Un valor mayor que 0 indica que usuarios sin privilegios pueden crearlos en muchos sistemas.

Cómo mitigarlo

1. Actualizar el kernel (la única corrección completa)

En Debian:

bash
sudo apt update
sudo apt full-upgrade
sudo reboot

En AlmaLinux, mientras el kernel siga en el repositorio de pruebas:

bash
sudo dnf install -y almalinux-release-testing
sudo dnf update 'kernel*' --enablerepo=almalinux-testing
sudo reboot

Después, desactiva el repositorio de pruebas en producción:

bash
sudo dnf config-manager --disable almalinux-testing

Si usas otra distribución, consulta su aviso oficial. En los hosts de virtualización, migra o apaga los invitados antes de reiniciar.

2. Verificar tras el reinicio

bash
uname -r
uname -v

El kernel anterior sigue en ejecución hasta reiniciar, aunque el paquete ya esté instalado.

3. Si todavía no hay parche: mitigaciones parciales

CloudLinux las describe como parciales y sin probar contra este fallo. Cada una elimina solo un requisito del ataque y ninguna sustituye al parche.

Desactivar el offload de checksum en las VMs (reduce el rendimiento de red del invitado y requiere reiniciarlo).

Con QEMU, en el dispositivo virtio-net-pci:

text
csum=off,guest_csum=off

Con libvirt, dentro del elemento <driver> de la interfaz:

xml
<host csum='off'/>
<guest csum='off'/>

Bloquear los user namespaces sin privilegios (solo cubre la ruta local):

bash
sudo sysctl -w user.max_user_namespaces=0
echo "user.max_user_namespaces = 0" | sudo tee /etc/sysctl.d/99-pwnescape.conf

Esto puede romper contenedores sin privilegios de root y los sandboxes de Chrome y Flatpak.

Livepatch: si usas KernelCare, revisa si ya hay un parche en vivo para tu distribución. Su disponibilidad variaba entre versiones al momento de publicarse el aviso.

Si eres cliente de un VPS

El código vulnerable está en el kernel del host, no en el de tu servidor virtual. Actualizar tu propio sistema no cierra esta puerta.

Lo que puedes hacer:

• Preguntar a tu proveedor si ya parcheó los hosts.
• Mantener tu propio kernel actualizado.
• Tratar con cautela los datos muy sensibles hasta recibir confirmación.

Si sospechas que ya fue explotada

• Revisa reinicios o caídas inesperadas del host.
• Busca errores del kernel con journalctl -k.
• Revisa el comportamiento anómalo de la red en las VMs.
• Los avisos consultados no publican indicadores de compromiso, por lo que la revisión debe ser general.

Conclusión

CVE-2026-99999 es una vulnerabilidad seria del kernel de Linux, especialmente para quienes ejecutan máquinas virtuales de terceros. La corrección existe en el kernel principal y en Debian, y está llegando a otras distribuciones.

Los pasos son claros: revisa tu kernel, comprueba si alojas VMs de terceros, actualiza y reinicia de forma ordenada. Si aún no hay parche para tu distribución, aplica las mitigaciones parciales sabiendo que no son una solución completa.

Mientras las fuentes no se pongan de acuerdo en la severidad y en la explotación, la opción prudente es no esperar.

Nota: Este artículo se basa en las publicaciones de Debian, Red Hat, AlmaLinux, CloudLinux y PWNAI Research, consultadas hasta el 20 de octubre de 2026. El estado de los parches cambia rápido y las fuentes aún presentan discrepancias. Antes de actuar, consulta el aviso vigente de tu distribución:

• Debian: https://security-tracker.debian.org/tracker/CVE-2026-99999
• Red Hat: https://access.redhat.com/security/cve/cve-2026-99999
• AlmaLinux: https://almalinux.org/blog/2026-10-16-pwnescape-cve-2026-99999/
• CloudLinux: https://blog.cloudlinux.com/cve-2026-99999-guest-to-host-escape
• Investigación original: https://pwn.ai/blog/pwnescape