📻 Versión en audio: si prefieres escuchar en vez de leer, el resumen del artículo está justo aquí arriba.
Firecracker es el hipervisor microVM que corre detrás de AWS Lambda y Fargate, y que cada vez más plataformas usan para aislar código que no confían: agentes de IA que ejecutan código, sandboxes de CI, funciones serverless. La promesa es simple: si el código invitado se descontrola, queda encerrado en su microVM y el host ni se entera. Hace unos días, los investigadores de PWN Research publicaron la segunda parte de su proyecto PwnEscape, y la promesa quedó un poco más frágil: demostraron cómo, partiendo desde adentro del invitado, terminaron ejecutando código como root en el host.
La cadena, traducida al castellano
La pieza se llama CVE-2026-99999: un primitivo que le permite al invitado leer memoria física del host a través de un mapeo. Con eso armaron una cadena elegante, paso a paso:
Primero, desde adentro de la microVM escribieron un patrón reconocible (un nonce) en una página de memoria propia. Con la traducción de tablas EPT buscaron esa misma página en la memoria física del host, hasta encontrarla por su contenido. Ese hallazgo les entregó un objeto conocido en memoria ajena: el punto de anclaje de todo lo que vino después.
Luego lo recorrieron al revés: en vez de traducir dirección virtual a física, buscaron qué mapeos del host apuntaban a esa página, y con eso recuperaron el directorio raíz de tablas de páginas (PGD) del proceso Firecracker. Con el PGD pudieron leer su código, su stack y su imagen ELF, incluso con ASLR activo: la diferencia entre una dirección del binario y su dirección en runtime les regaló el load bias.
El golpe final: el proceso Firecracker tiene un hilo por cada vCPU, y cuando el invitado dispara un evento, ese hilo sale de la instrucción ioctl(vcpu_fd, KVM_RUN, 0) y vuelve a espacio de usuario. Los registros guardados de esa llamada son una foto del hilo completo. Los investigadores buscaron en memoria el frame pt_regs cuyo instruction pointer coincidiera con la continuación validada del ioctl, y reescribieron los registros para que, al volver de KVM, el hilo ejecutara la llamada que ellos eligieron: un write() a stderr del propio proceso. Después restauraron el stack, y la VM siguió vivita y coleando por SSH.
El payload de la demo es inofensivo (imprimir un string), pero el mecanismo es ejecución arbitraria de código como root en un proceso que administra máquinas virtuales. No necesitas más para hacer lo que quieras con todo lo que corre en ese host.
Por qué me importa, aunque no administre Lambda
En mis VPS ejecuto cada vez más código que no escribí yo: scripts que un agente genera, crons que arman artículos, herramientas open source que corro con menos revisión de la que admito en público. Y cuando toca aislar algo, la conversación típica es «lo meto en un contenedor y listo». Esta cadena es un buen recordatorio de que el aislamiento no es binario: un contenedor comparte kernel con el host, una VM comparte hipervisor con el host. Son capas distintas con agujeros distintos, y ningún diseño es una caja de seguridad.
Lo que sí puedo hacer con lo que aprendí acá: primera, si tu plataforma corre Firecracker (o microVMs en general), la actualización del parche deja de ser «cuando pueda» para ser «esta semana». Segunda, el jailer, seccomp y correr cada VM con usuarios separados no impiden este ataque — el hijack ocurre en el proceso que ya administra la VM — pero sí reducen el radio de daño cuando fallan otras capas. Tercera, y es mi opinión de fondo: el control más barato sigue siendo saber qué estás ejecutando. Un sandbox perfecto no existe; un inventario de lo que corre en tus máquinas, sí, y lo tienes al alcance de una tarde de pega.
La cadena completa, con pseudocódigo, hashes de artefactos y manifiesto verificable por SHA-256, está publicada por los investigadores. Vale la pena leerla aunque no toques virtualización: es un curso exprés de cómo una sola primitiva de lectura de memoria escala hasta root si el resto del stack no pone resistencia.
Fuente: Firecracker VM Escape: PwnEscape Part 2, PWN Research.
Fuente de inspiración: Firecracker VM Escape: PwnEscape Part 2 – PWN.AI Security Research
