Un fallo crítico en el kernel de Linux podría permitir que una máquina virtual (VM) controlada por un atacante rompa su límite de aislamiento y afecte al sistema anfitrión. Esta vulnerabilidad, identificada como CVE-2026-99999 y denominada PwnEscape por el investigador Paulos Yibelo, se origina en el código de red de Linux y no en un hipervisor específico.

Paulos Yibelo demostró una técnica que expone la memoria del anfitrión y que, en su laboratorio, progresó hasta la ejecución de código a nivel de host. El fallo es grave para los proveedores de la nube y las organizaciones que ejecutan cargas de trabajo no confiables en máquinas virtuales. El aislamiento de las VM está diseñado para evitar que el código dentro de un invitado llegue al anfitrión y a otras cargas de trabajo.

PwnEscape muestra cómo una debilidad en la ruta de procesamiento de paquetes de un anfitrión puede amenazar ese límite, incluso cuando el problema subyacente no está en el hipervisor mismo.

Vulnerabilidad del Kernel PwnEscape

Linux puede retrasar el cálculo de la suma de comprobación (checksum) de un paquete de red. Esta es una característica normal de rendimiento: los metadatos del paquete indican al kernel dónde debe comenzar la operación de checksum y dónde debe escribirse el resultado.

Según el informe de PwnEscape de Paulos Yibelo, el problema ocurría cuando metadatos de paquetes menos confiables podían influir en una escritura posterior en una cabecera IPv4. Linux ya había procesado el paquete utilizando el contenido previo de la cabecera, pero antes de la fragmentación, la operación de checksum diferida podía cambiar esos contenidos. Posteriormente, el código dependía de la longitud actualizada de la cabecera IPv4.

En el caso de prueba de Paulos Yibelo, el paquete parecía inicialmente tener una cabecera IPv4 estándar de 20 bytes. Tras la escritura diferida, la cabecera podía interpretarse con una longitud de 60 bytes. El código de fragmentación podía entonces tratar los bytes más allá de los datos lineales válidos del paquete como parte de la cabecera e incluirlos en un paquete saliente. Informó que esto exponía 32 bytes de la memoria del anfitrión.

Esa divulgación no es lo mismo que la ejecución de código. El informe describe una cadena de laboratorio controlada y separada en la que los investigadores utilizaron observaciones de la memoria del anfitrión y gestionaron cuidadosamente el comportamiento de la asignación para demostrar escrituras seleccionadas en la memoria del kernel y ejecutar un ayudante de root en el anfitrión. Indican que este resultado se reprodujo en sistemas propiedad del investigador, no como prueba de ejecución de root en el entorno de producción de un proveedor de la nube.

La distinción es importante para que tú evalúes el riesgo. Una fuga de memoria del anfitrión puede revelar información que debería permanecer fuera del alcance de un invitado. Pueden ser necesarios pasos adicionales para convertir esa primitiva en el control del anfitrión, y el informe no establece que cada VM o hipervisor de Linux sea igualmente vulnerable.

El parche upstream de Linux añade una comprobación antes de ciertas operaciones de finalización de checksum. Verifica que el inicio del checksum no esté dentro de la cabecera IPv4. Si los metadatos fallan la comprobación, el kernel no procede con esa escritura de checksum a lo largo de la ruta afectada. El cambio cubre varios consumidores, incluida la fragmentación IPv4.

El commit describe el cambio como una medida de defensa en profundidad. También señala que una validación más fuerte en la entrada de paquetes requiere más trabajo. En otras palabras, el parche añade protección en los lugares donde el kernel completa los checksums, pero no se presenta como un rediseño completo de cómo entran todos los metadatos de checksum en la pila de red.

Deberías revisar los avisos de seguridad de tu proveedor de Linux e instalar un kernel actualizado que incluya la corrección. El commit upstream puede ayudarte a identificar el cambio, pero las distribuciones de Linux pueden aplicar correcciones de seguridad (backport) a versiones anteriores del kernel. Un número de versión por sí solo puede no mostrar si un sistema está protegido, así que comprueba el aviso del proveedor y confirma que tu sistema esté ejecutando el kernel actualizado.

PwnEscape nos recuerda que la seguridad de las VM depende de más que el hipervisor. El tráfico del invitado también pasa por componentes del sistema operativo anfitrión, incluyendo el código de red. Cuando los metadatos pueden desencadenar una escritura más tarde en el procesamiento del paquete, las comprobaciones realizadas anteriormente pueden ya no describir el paquete que ve un componente posterior.

El descubrimiento surgió del desafío de seguridad Sandbox de 1 millón de dólares de Vercel, que invitó a investigadores a probar sus controles de aislamiento. Paulos Yibelo, de pwn.ai, informó del fallo del kernel de Linux al tercer día mientras trabajaba desde un sandbox estándar sin acceso especial. Vercel lo calificó como el hallazgo más importante del programa.

El desafío recibió 1.285 informes durante dos semanas y pagó un total de 242.000 dólares en recompensas, siendo el fallo del kernel el único hallazgo calificado como crítico.

Para los defensores, el paso inmediato es seguir las actualizaciones del proveedor y parchear los hosts de Linux que ejecutan máquinas virtuales. El fallo subyacente fue una discrepancia entre los metadatos del paquete y la cabecera IPv4 en la que confiaba el código posterior. Esto hace que la corrección sea importante no solo para los proveedores de virtualización, sino también para los equipos que dependen del procesamiento de red de Linux para mantener contenidas las cargas de trabajo no confiables.