PwnEscape: fallo crítico en el kernel Linux, de la VM al host

Una vulnerabilidad crítica en la pila de red del kernel Linux, llamada PwnEscape y registrada como CVE-2026-99999, permite a una máquina virtual invitada leer partes de la memoria del host y, con una cadena de exploits más larga, llegar a ejecutar código en el host. Informaron de ella The Hacker News y CSO Online el 16 de octubre de 2026, y The Register y heise Security el 19 de octubre. Según The Register, el fallo tiene una puntuación de 9.3.

Ninguna de las fuentes habla de explotación activa, pero el investigador que lo descubrió prevé exploits funcionales en pocas semanas.

Quién lo descubrió

Según CSO Online, el fallo lo encontró Paulos Yibelo, de Pwn.ai, durante el desafío de seguridad de 1 millón de dólares lanzado por Vercel el 18 de agosto sobre su entorno Vercel Sandbox, que invitaba a los investigadores a romper el aislamiento de las máquinas virtuales. Vercel lo calificó como el hallazgo más grave recibido por el programa: el bloqueo y la ejecución de código se demostraron en máquinas KVM y Firecracker del propio investigador, configuradas como Vercel Sandbox, y según la empresa no hay indicios de acceso a datos de clientes.

El mecanismo técnico

El problema está en el checksum offloading: Linux puede aplazar el cálculo del checksum de un paquete a una fase posterior, y los metadatos del paquete indican dónde empieza el cálculo y dónde se escribe el resultado. Si esos metadatos proceden de un invitado, es decir, de un dominio menos fiable, pueden hacer que la escritura caiga dentro de la cabecera IPv4, que el kernel ya ha comprobado y utilizado.

Según CSO Online, Yibelo demostró que, tras las comprobaciones, la longitud de la cabecera IPv4 puede pasar de 20 a 60 bytes: el código de fragmentación, al volver a leer la cabecera, trata como cabecera datos que están más allá del paquete e introduce 32 bytes de memoria contigua del host en un paquete saliente. Es un fallo de tipo TOCTOU (time-of-check/time-of-use), pero sin la clásica carrera entre hilos: la escritura diferida se produce en el recorrido normal de los paquetes. Un análisis de SOC Prime citado por The Register subraya que la fuga se puede repetir, de modo que un invitado puede recoger información del host poco a poco.

Después, Yibelo usó esta lectura, junto con otras técnicas, para obtener escrituras dirigidas en la memoria del kernel y ejecutar un programa como root en el host. Afirma haber completado la cadena en laboratorio, en sus propios sistemas, en cuatro arranques en frío distintos; los detalles de esta parte aún no son públicos.

Según The Register, Red Hat indica como posible impacto la ejecución de código arbitrario en el host, un bloqueo del sistema (denegación de servicio) o la divulgación de memoria sensible. En MITRE ATT&CK el escenario corresponde a T1611, Escape to Host.

No solo KVM

The Register presenta el fallo como un escape invitado-host de KVM, el hipervisor que usan la mayoría de las grandes nubes. Sin embargo, según CSO Online, Yibelo precisa que el defecto no es específico de KVM ni de otro hipervisor: está en la pila de red de Linux que gestiona el tráfico de los invitados. El investigador habla de una nueva clase de ataques: metadatos de checksum no fiables que reescriben campos sensibles de los paquetes después de que el kernel los haya validado.

Corrección y versiones

La corrección aceptada, el commit 6785011f8b16, añade comprobaciones antes de las operaciones de finalización del checksum, para impedir que la escritura corrompa la cabecera IPv4. Según CSO Online, entró en el árbol de desarrollo el 8 de octubre y en el kernel principal el 14 de octubre; la descripción de la vulnerabilidad en NVD enumera correcciones en las ramas estables 5.10, 5.15, 6.1, 6.6, 6.12, 6.18 y 7.2, además de la de la rama principal. Las fuentes no indican los números exactos de las versiones corregidas de cada rama. Yibelo describe el parche como una medida de defensa en profundidad y advierte de que la validación de los metadatos de checksum no fiables todavía debe ampliarse.

Según The Register, la corrección está llegando a las principales distribuciones (Debian, RHEL, Ubuntu) y tendrá que llegar a los productos de virtualización basados en KVM, como Nutanix y Proxmox. El mismo medio informa de que AWS declara que EC2 no está en riesgo y de que Google Cloud, por la forma en que usa KVM, probablemente tampoco lo esté.

Por qué importa a las empresas europeas e italianas

Muchas empresas ejecutan servidores virtuales en hosts Linux: clústeres Proxmox, plataformas OpenStack, soluciones hiperconvergentes basadas en KVM, además de micro-VM usadas para aislar contenedores, pipelines CI/CD y agentes de IA. Allí donde comparten host cargas con distintos niveles de confianza (clientes diferentes, pruebas y producción, código de terceros), un escape desde el invitado rompe justo el aislamiento en el que se basa la separación.

Para las entidades NIS2 de infraestructuras digitales y gestión de servicios TIC, como proveedores de nube, centros de datos y proveedores de servicios gestionados, la actualización forma parte de la gestión de vulnerabilidades; cualquier incidente significativo debe evaluarse para su notificación al CSIRT nacional (en Italia, el CSIRT Italia de la ACN). En el sector sanitario conviene incluir los entornos virtualizados que alojan aplicaciones clínicas.

Qué hacer ya

1. Localiza los hosts afectados: hipervisores Linux con KVM, hosts que ejecutan micro-VM como Firecracker y appliances de virtualización basados en Linux.
2. Actualiza el kernel de los hosts en cuanto tu distribución o tu proveedor publiquen el paquete con la corrección: busca CVE-2026-99999 en sus boletines. El nuevo kernel requiere reiniciar el host (o un parche en caliente, si tu proveedor lo ofrece): planifica la migración de las VM.
3. Da prioridad a los hosts que ejecutan código no fiable o de varios clientes: hosting, plataformas multiinquilino, sandboxes, runners de CI, laboratorios.
4. Pregunta a tus proveedores de nube privada, hosting y appliances cuándo aplicarán la corrección.
5. Mientras tanto, las fuentes no mencionan soluciones temporales: mantén las cargas menos fiables lejos de los hosts más críticos.
6. Vigila los hosts: bloqueos o errores del kernel relacionados con la red, procesos inesperados con privilegios de root, procesos hijos anómalos del hipervisor. No se han publicado indicadores de compromiso.

Cómo ayuda ARXDOME

El inventario de ARX Sentry muestra el sistema, el software y los procesos de los servidores Linux con el agente: te ayuda a encontrar los hosts de virtualización y sus versiones del kernel. ARX Shield muestra las vulnerabilidades abiertas por máquina y por paquete, para que sigas la actualización host por host.

Última actualización: 19 de octubre de 2026