Firecracker: escape de microVM logra root en el host

Firecracker: un escape de microVM que termina en root sobre el host

Investigadores de pwn.ai publicaron la segunda parte de PwnEscape, una cadena de explotación que logra ejecución de código como root en el host partiendo desde dentro de una microVM de Firecracker. El objetivo fue Firecracker v1.16.1 sobre x86-64, con kernel de host 7.0.0-1011-aws y kernel invitado 6.18.44+; el proceso se lanzó directamente como root bajo systemd-run y se fijó con taskset. Los propios autores enmarcan el trabajo como una demostración de CVE-2026-99999 sobre un entorno de Firecracker.

Para un founder que corre código de terceros en sandboxes, el dato tiene una implicación directa: Firecracker es la tecnología de virtualización que AWS desarrolló para acelerar servicios como Lambda y Fargate, y que también se integró en runtimes de contenedores como Kata Containers. La promesa de la microVM es que el código no confiable se queda adentro. Este trabajo muestra una cadena completa para salir y decidir qué ejecuta el proceso anfitrión.

Cómo se encadena el escape: de una página del guest al hilo del vCPU

La primera parte de PwnEscape había construido una primitiva de acceso a memoria física del host desde el guest. La segunda parte usa esa primitiva para encontrar Firecracker en memoria y tomar el control de un hilo vivo.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

El punto de partida es la arquitectura de Firecracker: cada CPU virtual (vCPU) tiene un hilo en el proceso del host. Ese hilo entra en KVM para ejecutar el guest y vuelve a Firecracker cuando hay un evento que resolver en espacio de usuario, mediante la llamada ioctl(vcpu_fd, KVM_RUN, 0). Mientras el hilo está dentro de esa llamada al sistema, el kernel del host guarda sus registros de usuario en una estructura llamada pt_regs. Ahí está el puntero de instrucción que dice dónde debe reanudar la ejecución y el puntero de pila que dice qué stack usar.

La cadena se resuelve en cuatro resolutores encadenados:

Resolver de EPT. El guest coloca un patrón de bytes reconocible (un nonce) en una página propia. El resolver busca raíces de Extended Page Tables candidatas, camina las tablas hasta llegar a una página física y comprueba si contiene el nonce. Eso conecta una traducción propuesta con memoria que el atacante controla. El resultado fue guest_page_hpa = 0x165610000.
Reverse mapper. En lugar del recorrido habitual (de dirección virtual a física), busca en las tablas de páginas nativas del host una traducción hacia esa página física conocida y recupera la raíz de tablas asociada. Así obtiene host_pgd = 0x14afc2000, el espacio de direcciones del proceso de Firecracker.
Image mapper. Identifica la imagen ELF de Firecracker dentro de esas traducciones y verifica una secuencia de bytes conocida en el wrapper de write(2). Con eso recupera el load bias que anula el efecto de ASLR: firecracker_base = 0x7298c2400000.
Frame finder. Busca en memoria del host un frame pt_regs coherente con una llamada a KVMRUN activa: identidad de la llamada al sistema, el request KVMRUN, el descriptor de archivo en rango, el puntero de instrucción apuntando a la continuación del ioctl en Firecracker, el puntero de pila traducible por el PGD recuperado y selectores de segmento válidos. Quedó un único candidato: frame_hpa = 0x13a5bff48.

El retorno de KVM_RUN: dónde se toma el control

Con el frame localizado, el payload elegido fue deliberadamente simple: hacer que Firecracker escribiera una cadena reconocible en su propio stderr. La llamada objetivo fue write(2, "N8V23M2\n", 8), con el marcador almacenado en la pila privada del proceso.

El helper guardó tres palabras de pila antes de modificarlas y luego reescribió los registros guardados: el puntero de instrucción apuntando al wrapper de escritura, los argumentos de la llamada y un puntero de pila hacia una secuencia temporal de retorno. El detalle fino está en la vuelta: una escritura exitosa de ocho bytes devuelve 8, mientras que un KVM_RUN exitoso devuelve cero. Por eso la secuencia de retorno empieza con xor eax,eax; ret, que limpia el valor de retorno antes de devolver la ejecución a la continuación original del ioctl.

El disparador fue una operación del guest: escribir un byte en su puerto serie. Eso provoca que el hilo del vCPU vuelva de KVM_RUN, el kernel restaura los registros modificados y Firecracker entra en el wrapper de escritura con los argumentos elegidos. Después, el hilo retoma su camino original y el helper restaura las tres palabras de pila.

La verificación es lo más sólido del reporte. El host capturó el stderr de Firecracker por separado: contenía exactamente el marcador, ocho bytes en total. El proceso seguía vivo con PID 2936, el SSH del guest respondía con un uptime de 1615,72 segundos, las tres palabras de pila quedaron restauradas, el texto ejecutable y las librerías compartidas no se modificaron y no se observaron errores del kernel del host. Una segunda pasada sin cambios de memoria repitió los chequeos y volvió a pasar.

Qué configuración hizo posible el root en el host

El propio reporte es explícito sobre el alcance: la configuración usada no tenía jailer. Firecracker se lanzó como root y el proceso conservó esos privilegios, así que la llamada controlada se ejecutó como root.

Eso importa porque el modelo de contención de producción de Firecracker es más estricto que el del laboratorio. La documentación oficial del proyecto describe que el jailer arranca Firecracker aplicando una barrera de aislamiento por cgroups y namespaces y después baja privilegios, además de incluir filtros seccomp específicos por hilo. En otras palabras: el escape demuestra control sobre el hilo del VMM, pero un despliegue con jailer, privilegios reducidos y seccomp obliga a una evaluación separada de qué privilegios y recursos quedan disponibles después de comprometer el monitor de máquinas virtuales.

¿Sigue siendo la microVM una frontera confiable?

El contexto de 2026 empuja en dos direcciones a la vez. En agosto de 2026, Trail of Bits publicó un experimento controlado en el que un agente de IA de seguridad escapó tres veces de una máquina virtual QEMU/KVM, incluida una cadena con vulnerabilidades de día cero descubiertas de forma autónoma, según reportó TechTimes. En ese mismo experimento, el agente no logró escapar de un sandbox basado en Firecracker dentro de la ventana de prueba, aunque sí consiguió bloquear el host. El investigador Artem Dinaburg lo resumió así: Firecracker es un objetivo sustancialmente más difícil, pero no una garantía absoluta.

El trabajo de pwn.ai no contradice ese veredicto: lo precisa. La superficie de dispositivos emulados de Firecracker es mínima por diseño —sin adaptador de video, sin USB, sin audio, sin BIOS emulada—, pero el hilo del VMM, el retorno de KVM_RUN y la interfaz con el kernel del host siguen existiendo, y ahí es donde vive esta cadena. Para dimensionar el peso de Firecracker en la industria: AWS lo presentó en noviembre de 2018 bajo licencia Apache 2.0, una microVM puede arrancar en tan poco como 125 milisegundos y consumir menos de 5 MiB de memoria, según TechTarget.

Qué significa esto para tu startup

Si tu producto ejecuta código que no controlas —plugins de usuarios, jobs de terceros, agentes de IA con acceso a shell—, la lección no es abandonar la virtualización, sino dejar de tratarla como una frontera única.

Activa el jailer y no corras el VMM como root. El propio reporte señala que la configuración sin jailer fue la que permitió que la llamada controlada se ejecutara con privilegios de root. El jailer aplica aislamiento por cgroups y namespaces y luego baja privilegios; los filtros seccomp por hilo vienen incluidos en el proyecto.
Trata el kernel del host como parte de tu superficie de ataque. El escape depende de la interfaz KVM y del estado del hilo del VMM, no de un dispositivo emulado. Mantén el host parcheado y asume que la microVM no te protege de un kernel desactualizado.
Haz cada ejecución desechable. Si un sandbox se compromete, el daño debería limitarse a un entorno limpio y efímero. Provisionar un entorno nuevo por corrida es una de las mitigaciones que recomienda el propio Trail of Bits.
Registra el stderr del VMM y el comportamiento del guest. En esta demostración, la prueba de la toma de control fue un marcador de ocho bytes en el stderr de Firecracker. Ese tipo de salida anómala es exactamente lo que un sistema de logging bien puesto debería capturar.

La conclusión práctica para un equipo pequeño es incómoda pero clara: el aislamiento por microVM sigue siendo la mejor herramienta disponible para correr código no confiable, y a la vez deja de ser suficiente por sí sola. La diferencia entre un sandbox que aguanta y uno que no suele estar en la configuración —jailer, privilegios, seccomp, parcheo del host—, no en la tecnología elegida.