martes, 6 de octubre de 2026
Infra crew

Infraestructura TI con contexto

Virtualización

Una señal apunta a un escape de invitado a root en KVM, sin CVE ni parche

·2 fuentes

Por InfraCrew Editorial · Criterios editoriales y correcciones

Una señal no confirmada apunta a un escape de invitado a root del host en KVM, ligado al bounty de Vercel Sandbox y Firecracker. No hay CVE, parche ni aviso de los mantenedores. El alcance a otras plataformas no está demostrado.

Chasis de host abierto con una microVM a medio salir de la bahía y una carpeta marcada sin CVE, con una etiqueta InfraCrew en el asa.

Un investigador dice haber salido de una máquina virtual y haber llegado a root del host en un hipervisor basado en KVM. Vercel, que usa microVM de Firecracker en su Sandbox, afirma haber confirmado un zero-day dentro de su programa de bug bounty. No hay CVE, no hay parche de kernel, no hay aviso de los mantenedores de KVM y no hay detalle técnico público. Hasta ahí llega lo confirmado. El resto, incluido el alcance a nubes públicas o a Proxmox, es una hipótesis.

Qué se ha dicho, y quién lo ha dicho

Paulos Yibelo publicó en X una captura de un premio de bug bounty y describió el hallazgo como un escape completo de invitado a root del host «en hipervisores estándar de la industria». The Register recogió el caso el 6 de octubre y sitúa el programa en Vercel Sandbox, que ejecuta cargas en Firecracker, la tecnología de microVM que nació en AWS y se apoya en KVM. El consejero delegado de Vercel, Guillermo Rauch, escribió que habían confirmado un zero-day de KVM en ese programa y lo llamó un problema del «estándar de oro» de la virtualización Linux.

Cybernews añade que la notificación del bounty hablaría de un escape de microVM hacia un host de tipo EC2, con lectura, modificación y ejecución entre inquilinos. Esa frase sale de la cobertura del medio y de la captura que enseña el investigador. No es un advisory de AWS ni un comunicado de los mantenedores del kernel. Nadie ha publicado el diff, la syscall ni la versión afectada.

-InfraCrew dice: «Lo hemos confirmado» es una frase excelente hasta que preguntas confirmado dónde, en qué build y con qué parche.-

Por qué importa aunque no haya ficha

KVM no es un producto de nicho. Es el hipervisor del kernel Linux que usan nubes, plataformas de virtualización y sandboxes. The Register recuerda que Nutanix, HPE y Proxmox también se apoyan en KVM, y que Firecracker, al ser abierto, puede estar en muchos sitios además de Vercel. Si el fallo estuviera en KVM de forma genérica, el radio sería el de medio parque de anfitriones Linux. Si estuviera en una combinación concreta de Firecracker, versión de kernel y dispositivo virtual, el radio sería otro. Hoy no hay forma pública de distinguir las dos lecturas.

Eso obliga a separar tres capas. Primera: Vercel dice haber validado un informe dentro de su bounty. Segunda: el investigador afirma un escape a root. Tercera: el resto de la industria no ha confirmado producto, versión ni corrección. Mezclarlas produce un titular de «KVM está roto» que las fuentes no sostienen.

Qué no se puede afirmar

No hay identificador CVE asignado en las fuentes consultadas. No hay nota de los mantenedores de KVM, ni de AWS como autora de Firecracker, que describa el fallo o una mitigación. No hay prueba de explotación fuera del programa de bounty. Un premio de bug bounty no es lo mismo que un ataque en producción, y una confirmación del cliente del bounty no sustituye al aviso del proyecto. Tampoco se sabe si el fallo exige una configuración de dispositivo, una versión vieja del kernel o un camino solo presente en el sandbox de Vercel.

-InfraCrew dice: El inventario de hipervisores acaba de pedir una columna nueva llamada «ya, pero todavía no».-

Proxmox, Nutanix AHV u otros productos basados en KVM no han publicado, en lo que se ha podido comprobar, un aviso ligado a este informe. Citarlos como afectados sería convertir una lista de quien usa KVM en una lista de víctimas. The Register los nombra como posibles interesados, no como plataformas comprometidas.

Qué puede hacer quien opera hosts

Mientras no haya versión ni vector, no hay parche que recomendar ni workaround oficial que aplicar. Lo razonable es anotar la señal, vigilar los canales de seguridad del kernel y de la plataforma concreta, y no abrir un cambio de arquitectura por un post. Si el sandbox de agentes corre sobre Firecracker o sobre KVM expuesto a invitados no confiables, el dueño de esa plataforma es quien tiene que decir si el informe le afecta. El resto puede preparar el inventario de hosts KVM y de la versión de kernel, que es lo que hará falta el día que salga el aviso.

La incertidumbre es el centro de la noticia, no un pie de página. Puede ser un escape grave de hipervisor. Puede quedar contenido en un camino de Firecracker que la mayoría de clusters no usa. Hasta que haya ficha, build y parche, las dos frases caben en el mismo párrafo.

Diccionario de la Crew

KVM — Hipervisor del kernel Linux que permite ejecutar máquinas virtuales como procesos del anfitrión. Aquí es la capa que el informe señala, sin versión publicada.
CVE — Identificador público de una vulnerabilidad. En este caso todavía no hay uno asociado al supuesto escape.
Firecracker — MicroVM de código abierto, originada en AWS, que usa KVM para aislar cargas de corta duración. Vercel Sandbox se apoya en ella.

The Register | https://www.theregister.com/offbeat/2026/10/06/security-researcher-claims-to-they-found-kvm-guest-host-escape-flaw/5301267
Cybernews | https://cybernews.com/security/critical-kvm-zero-day-vulnerability-allows-vm-escape/

Fuentes consultadas