Una nueva vulnerabilidad crítica en el kernel de Linux, revelada recientemente, permite que el código que se ejecuta dentro de una máquina virtual acceda a la memoria del ordenador anfitrión. Un investigador ha demostrado el fallo en los entornos de ejecución en la nube de Vercel, y la compañía lo ha confirmado.
La falla, registrada como CVE-2026-99999 y apodada PwnEscape, se encuentra en el código de red del kernel de Linux, no en la configuración de un proveedor concreto, por lo que afecta a la capa compartida que los proveedores cloud utilizan para aislar las cargas de trabajo de sus clientes.
Fue descubierta en un desafío de seguridad organizado por Vercel y notificada de forma privada antes de su divulgación pública. No hay indicios de que se haya explotado en un ataque real.
Lo que demostró el investigador
Paulos Yibelo, de la firma de seguridad pwn.ai, descubrió que paquetes de red especialmente diseñados, enviados desde dentro de una máquina virtual, podían lograr tres cosas, según explicó en un informe técnico: leer la memoria del host, provocar su caída y ejecutar código en él. Las tres derivan de la misma falla del kernel.
Vercel señaló en su informe sobre el desafío que la fuga de memoria se demostró contra sus sandboxes de producción. Cada paquete que enviaba el invitado podía devolver unos 32 bytes de memoria del host, y el invitado podía continuar mientras siguiera enviando paquetes.
La caída y la ejecución de código solo se observaron en las máquinas del propio investigador, configuradas para imitar las de Vercel. Dos paquetes especialmente manipulados bastaron para tumbar un host y con él todos los sandboxes que ejecutaba.
Aprovechando la misma falla, el investigador consiguió el control administrativo de un host, escapando de la máquina virtual. Subrayó que se trata de un resultado de laboratorio, "no de una afirmación de ejecución de comandos root en el entorno de producción de ningún proveedor".
"Nuestra investigación se realizó con Omega-Pwn, un sistema interno que combina nuestras propias herramientas de investigación de seguridad con elementos de la arquitectura OmegaClaw de SingularityNET. Nos permitió arrastrar hipótesis, trazas de código, intentos fallidos y resultados experimentales a lo largo de sesiones de investigación prolongadas. GPT-5.6 Sol fue el motor de razonamiento principal. Dirigimos la investigación, cuestionamos sus hallazgos y validamos los interesantes contra el comportamiento real del kernel en sistemas que controlábamos", declaró Paulos Yibelo a The Hacker News.
Vercel afirmó que ningún informe del desafío mostró que alguien leyera archivos, secretos o datos de aplicaciones de un cliente.
Gravedad y quién puede desencadenarla
Los mantenedores del kernel asignaron a la falla el identificador CVE-2026-99999 y, en el registro publicado, la calificaron con 9,3 sobre 10, es decir, crítica. La Base de Datos Nacional de Vulnerabilidades de EE. UU. había recibido la entrada, pero aún no había completado su propia revisión.
El mismo registro indica que el vector de ataque es local. En términos sencillos, el atacante ya debe estar ejecutando código dentro de un invitado, como hizo el investigador. No es una falla que un externo pueda explotar enviando paquetes por internet abierta.
No figura en el catálogo de vulnerabilidades explotadas activamente de CISA y no se ha informado de ningún uso en el mundo real.
Por qué va más allá de Vercel
Vercel Sandbox ejecuta el código de cada cliente en su propia microVM de Firecracker, una pequeña máquina virtual con su propia copia del kernel de Linux, sobre hosts de Amazon EC2 sin virtualización. Esa microVM es el muro entre un cliente y el host, y entre un cliente y otro.
La falla no está en ese muro, sino en el código de red del kernel de Linux que ejecuta el host. pwn.ai señaló que el sandbox de Vercel ya estaba endurecido más allá de los estándares habituales del sector, sin ninguna mala configuración que pudiera encontrar.
Dado que casi todas las grandes nubes separan las cargas de trabajo de sus clientes en la misma capa del kernel de Linux, Vercel afirmó que una falla en ese punto representa un riesgo para la infraestructura compartida más que para un proveedor concreto.
La solución y las versiones corregidas
La solución es un único cambio en el kernel de Linux, el commit 6785011f8b16, escrito por Michael S. Tsirkin, de Red Hat, e integrado en el kernel principal. Añade una comprobación para que los datos de checksum de un paquete no puedan apuntar al encabezado IPv4 antes de que el kernel actúe sobre él, y aplica esa comprobación en cinco puntos del código de red.
El cambio es deliberadamente parcial. Su autor lo califica de "medida de defensa en profundidad" y señala que aún falta trabajo para una comprobación más completa en la entrada de paquetes al kernel.
Los mantenedores han trasladado el parche a las ramas estables del kernel. Según el registro del CVE, estas son las primeras versiones corregidas en cada rama soportada:
- Linux 5.10.254
- Linux 5.15.199
- Linux 6.1.152
- Linux 6.6.102
- Linux 6.12.35
- Linux 6.15.4
Las distribuciones de Linux distribuyen sus propios kernels y a menudo añaden este tipo de corrección sin cambiar el número de versión, así que conviene consultar el aviso de la distribución y comprobar si el parche está en el kernel que realmente ejecuta el host, no solo en el número que muestra uname.
Qué hacer
Actualiza el kernel del host a una de las versiones corregidas anteriores, o a la compilación del proveedor que incluya el parche, y reinicia con ella. Actualizar solo el kernel de un invitado no soluciona el problema del host. Las fuentes no ofrecen un método alternativo específico si no se puede actualizar todavía.
Cuando el parche tenga que esperar, lo habitual es limitar el alcance de una posible intrusión. Vercel indica que mantiene actualizados los kernels de los hosts, desactiva la virtualización anidada y ejecuta cada microVM bajo el jailer de Firecracker, que concede al proceso de la microVM solo los permisos necesarios. Eso no corrige la falla, pero reduce lo que un atacante que la aproveche podría hacer.
Encontrada en un desafío de un millón de dólares
La falla se encontró en un desafío de dos semanas que Vercel organizó en agosto y que ofrecía hasta un millón de dólares en total a quien lograra escapar de su sandbox. Ningún pago individual alcanzó esa cifra. La recompensa máxima por informe fue de 50.000 dólares; Vercel pagó 242.000 dólares por 1.285 informes, y esta falla fue el único hallazgo crítico.
pwn.ai afirma que encontró la falla en tres días usando su propio sistema de investigación asistido por IA, con el modelo encargado del análisis del código fuente y los investigadores humanos dirigiendo el trabajo. La firma calculó el coste en menos de 700 dólares en tokens de API. Es el último caso de investigadores que utilizan un modelo de lenguaje grande para ayudar a encontrar y encadenar fallas reales, después de que otro equipo lo usara a principios de este año para alcanzar sistemas internos de OpenAI.
Deja una respuesta