Un investigador demostró cómo explotar el mecanismo de checksum del kernel para acceder a memoria del host y ejecutar código con privilegios de root
El investigador de seguridad Paulos Yibelo de Pwn.ai descubrió una vulnerabilidad en el stack de networking del kernel Linux que permite a un atacante operando dentro de una máquina virtual romper la barrera de aislamiento y acceder al sistema host subyacente. La falla, denominada PwnEscape y rastreada como CVE-2026-99999, fue detectada mientras Yibelo participaba en el desafío de seguridad Sandbox de Vercel, anunciado el 18 de agosto con un premio de un millón de dólares. Vercel describió el hallazgo como el más severo recibido a través de su programa. El parche correctivo fue fusionado en el kernel mainline el 14 de octubre, después de haber sido aplicado al árbol de desarrollo el 8 de octubre mediante el commit 6785011f8b16.
Cómo el mecanismo de checksum diferido se convirtió en vector de ataque
PwnEscape explota el mecanismo de offloading de checksum del kernel Linux, diseñado para diferir el cálculo del checksum de un paquete de red hasta una etapa posterior del procesamiento. Los metadatos del paquete especifican dónde debe comenzar el cálculo y dónde debe escribirse el resultado. La vulnerabilidad surge cuando metadatos de checksum controlados por el atacante dirigen esa escritura hacia el encabezado IPv4 del paquete.
El kernel procesa inicialmente el paquete usando su encabezado original, pero una operación posterior de completado de checksum puede modificar ese encabezado antes de que el código de fragmentación lo consuma nuevamente. Yibelo demostró este comportamiento cambiando el campo de longitud interpretada del encabezado IPv4 de 20 bytes a 60 bytes. El código de fragmentación entonces trató bytes más allá de los datos válidos del paquete como parte del encabezado, permitiendo que 32 bytes de memoria adyacente del host se incluyeran en un paquete saliente.
Un problema de time-of-check/time-of-use sin condición de carrera tradicional
La falla es fundamentalmente un problema de time-of-check/time-of-use (TOCTOU): el kernel toma decisiones relevantes para la seguridad usando una versión del encabezado, luego actúa sobre una versión modificada sin revalidarla. Sin embargo, la secuencia no requiere la condición de carrera habitual entre hilos de ejecución. La escritura diferida ocurre durante operaciones normales de networking, según explicó Yibelo en su análisis técnico.
El investigador reportó haber encadenado la fuga de memoria con pasos de explotación adicionales para lograr escrituras selectivas en memoria del kernel y ejecutar código con privilegios de root del host en sus sistemas de prueba. Yibelo completó cuatro arranques en frío completos de una cadena de explotación en laboratorio que ejecutaba un helper con privilegios de root del host y devolvía un marcador generado por el host al guest. El investigador enfatizó que el problema no es específico de KVM ni de otro hipervisor particular, sino que reside en el stack de networking de Linux que maneja el tráfico del guest.
Siete versiones estables afectadas y un parche de defensa en profundidad
La vulnerabilidad afecta siete versiones estables del kernel Linux: 5.10, 5.15, 6.1, 6.6, 6.12, 6.18 y 7.2. El parche aceptado introduce validaciones antes de las operaciones relevantes de completado de checksum, previniendo que la escritura de checksum corrompa el encabezado IPv4 a lo largo de las rutas de procesamiento afectadas. Yibelo describió el cambio como una medida de defensa en profundidad, señalando que la validación más amplia de metadatos de checksum no confiables permanece como un área para trabajo futuro.
Andy Riancho, ingeniero principal de seguridad de Vercel, confirmó que no existen reportes de acceso a datos de clientes en Vercel Sandbox. Los ataques relacionados con paquetes y la ejecución de código fueron demostrados en las propias máquinas KVM y Firecracker del investigador, configuradas para coincidir con la infraestructura de Vercel Sandbox. El problema quedó resuelto antes de que se documentara explotación en producción.
Exposición regional por dependencia de infraestructura virtualizada
La dependencia de infraestructura virtualizada basada en Linux en América Latina amplifica la relevancia de PwnEscape para la región. Proveedores de nube pública y privada en Brasil, México, Argentina y Chile operan entornos de virtualización que procesan tráfico de red a través del stack del kernel Linux afectado. Aunque no hay datos públicos sobre explotación específica en LATAM, la naturaleza del vector de ataque — que no requiere condiciones de carrera complejas y puede ejecutarse en operaciones normales de networking — reduce la barrera técnica para su weaponización.
Yibelo advirtió que espera que la industria de seguridad use su publicación para identificar otros hipervisores afectados, y que exploits en configuraciones más débiles podrían aparecer en semanas, mientras que exploits funcionales en configuraciones predeterminadas de hipervisores podrían llegar en menos de un mes. Esta ventana temporal es crítica para organizaciones en la región que operan infraestructura virtualizada sin equipos de respuesta a incidentes dedicados o procesos de parcheo acelerados.
Nuestro análisis
PwnEscape expone un patrón recurrente en la seguridad del kernel: la complejidad de los mecanismos de optimización de rendimiento crea superficies de ataque no obvias. El offloading de checksum es una característica de rendimiento estándar, pero su interacción con el procesamiento de encabezados introduce una ventana TOCTOU que no requiere sincronización entre hilos — una variante del problema que las herramientas de análisis estático tradicionales no detectan fácilmente. El hecho de que Yibelo lograra una cadena de explotación completa en cuatro arranques en frío indica que la primitiva de fuga de memoria es suficientemente confiable para construir exploits estables, no solo pruebas de concepto frágiles.
La advertencia de Yibelo sobre la llegada de exploits en configuraciones predeterminadas en menos de un mes plantea una pregunta operativa concreta para organizaciones que ejecutan cargas de trabajo multi-tenant en Linux: ¿cuántas de ellas tienen capacidad de aplicar parches de kernel en ventanas de días, no de semanas, cuando la explotación de la vulnerabilidad no deja rastros evidentes en logs de aplicación y requiere visibilidad a nivel de tráfico de red del host para ser detectada?