Los escapes del sandbox vm2 convierten la inyección de prompts en RCE en el host

¿Qué es esto?

Durante el primer semestre de 2026, investigadores de seguridad divulgaron una oleada de vulnerabilidades de escape de sandbox en vm2, una biblioteca npm en su día popular para ejecutar JavaScript no confiable con restricciones, como una lista de permitidos de módulos limitada. Un primer escape crítico apareció en enero de 2026 (documentado por StepSecurity y Semgrep), seguido de un conjunto de más de diez identificadores adicionales los días 4 y 5 de mayo de 2026, la mayoría con puntuaciones entre CVSS 9.0 y 10.0 (Kodem Security, 14 de mayo de 2026).

Lo que convierte esto en un tema para un sitio de seguridad de IA, y no en un simple fallo de Node.js, es dónde se ubica vm2. Muchos frameworks de agentes de IA usan vm2 como capa de aislamiento para ejecutar el código que el propio modelo genera. El 7 de mayo de 2026, Microsoft Security Research puso nombre al problema estructural resultante: en los frameworks de agentes donde los prompts pueden influir en la lógica ejecutable, un escape de sandbox convierte una inyección de prompt en ejecución remota de código a nivel del host — «When prompts become shells».

Cómo funciona

La cadena tiene cuatro etapas, y ninguna requiere un exploit inédito: solo una primitiva de escape conocida y un agente configurado para ejecutar código generado.

Primero, JavaScript no confiable llega a vm2. En un producto con plugins o en SaaS, la fuente es código enviado por el usuario. En un agente, la fuente es la propia salida del modelo: una herramienta que permite al agente «escribir y ejecutar un script» ejecutará de buen grado un script hacia el que un atacante lo orientó mediante instrucciones inyectadas en una página web, un documento o el resultado de una herramienta.

Después, el código provoca un abuso de la frontera del sandbox. El aislamiento de vm2 se aplica casi por completo en JavaScript: reescritura de cláusulas catch, puenteo mediante proxy de los objetos que cruzan la frontera y parches uno a uno de las rutas de escape conocidas. Las divulgaciones de 2026 derrotan ese modelo cada una por una vía distinta: elusión de la sanitización de callbacks de promesas, abuso de SuppressedError y otras gestiones de excepciones, trucos con __lookupGetter__ y getPrototypeOf, desenvoltura de proxy mediante inspect() y cadenas de contaminación de prototipos. Todas producen el mismo resultado: una referencia, un callback o una búsqueda de propiedad que alcanza un objeto del realm del host.

// Forma vulnerable (ilustrativa): un agente ejecuta JS generado por el modelo en vm2
const { VM } = require('vm2');
const result = new VM().run(modelGeneratedCode); // [REDACTED] la primitiva de escape se ejecuta aquí

Sigue el acceso a las capacidades del host. Una vez fuera del sandbox, el código puede alcanzar el objeto process de Node y, desde ahí, child_process, el sistema de archivos y la red saliente. Uno de los avisos de mayo es precisamente una elusión de la lista de permitidos que lleva directo a child_process. La cuarta etapa es la ejecución de la carga útil: comandos de shell arbitrarios se ejecutan con los privilegios del runtime de Node.js, lo que en un despliegue de agente suele significar acceso a secretos de entorno, credenciales de nube y alcance a la red interna.

Por qué importa

La inyección de prompts por sí sola suele ser un problema de la capa de salida: el modelo dice algo que no debería. Encaminada a través de un sandbox de ejecución vulnerable, esa misma inyección se convierte en un problema de la capa de infraestructura: un atacante obtiene un shell en la máquina. Es un cambio cualitativo en el radio de impacto, y es exactamente la combinación señalada por Microsoft y por los equipos de respuesta que siguen la oleada.

Dos propiedades hacen de vm2 una mala apuesta para esta tarea. Tiene un historial de varios años de escapes de sandbox, y su mantenedor ha discontinuado el proyecto, por lo que los parches no son un flujo fiable. Y el modelo de aislamiento no tiene defensa estructural contra esta clase; cada CVE es una corrección puntual para una primitiva nueva, razón por la que 2026 produjo un conjunto en lugar de un solo fallo. Una suposición realista es que vendrán más variantes, y que el mismo enfoque de «prompts become shells» se extenderá a otros sandboxes de JavaScript a medida que los investigadores los examinen.

La pregunta práctica sobre la exposición no es «¿está vm2 instalado?» (un análisis SCA lo responde). Es si un prompt no confiable puede alcanzar una ruta de ejecución dinámica que pase por vm2 con herramientas reales conectadas. Una aplicación web que evalúa un script interno codificado a mano mediante vm2 y un agente que ejecuta código generado por LLM en vm2 con acceso a shell son idénticos en un manifiesto de dependencias y conllevan riesgos totalmente distintos.

Defensas

• No trate vm2 (ni ningún sandbox de JS en proceso) como una frontera de seguridad. Si debe ejecutar código no confiable o generado por el modelo, superponga un aislamiento real por debajo — un contenedor separado, gVisor o Firecracker — para que un escape aterrice en un entorno desechable y de mínimo privilegio en lugar de en su host.
• Aplique parches, pero planifique migrar. Actualice vm2 a la última versión parcheada para cerrar las primitivas divulgadas actualmente, y priorice abandonar la biblioteca discontinuada en favor de un enfoque activamente mantenido para la ejecución no confiable.
• Restrinja las herramientas del agente. Un agente que no puede llamar a child_process, no puede escribir fuera de un directorio temporal y no puede alcanzar destinos de red fuera de la lista de permitidos no puede convertir un escape de sandbox en un compromiso de infraestructura. La restricción de herramientas se despliega más rápido que rediseñar el modelo de ejecución.
• Retire las credenciales del contexto de ejecución. El proceso de Node.js que ejecuta código no confiable no debería portar claves de AWS/GCP, tokens de registro ni secretos de CI. Use tokens de alcance limitado y de vida corta, y elimine las credenciales ambientales.
• Supervise en tiempo de ejecución. Busque procesos node que lancen shells o llamadas a child_process, lecturas inesperadas de archivos como ~/.aws/credentials o /proc/self/environ, y tráfico saliente de un runtime de agente hacia dominios fuera de la lista de permitidos. El escape ocurre dentro del proceso, así que es la telemetría de comportamiento —y no solo el análisis de dependencias— la que lo detecta.
• Mapee sus rutas de ejecución. Inventaríe cada servicio donde vm2 aparezca en el árbol de dependencias directo o transitivo, y marque aquellos donde código no confiable o generado por LLM pueda alcanzarlo de verdad. Ese subconjunto es la exposición real.

Estado

Elemento	Valor
Componente afectado	vm2 (sandbox de Node.js para JavaScript no confiable), discontinuado por su mantenedor
Naturaleza	Múltiples fallos de escape de sandbox → RCE en el host
Ventana de divulgación	Ene. 2026 (CVE-2026-22709) y un conjunto del 4–7 de mayo de 2026 (10+ CVE, CVSS 9.0–10.0)
Relevancia para IA	Los frameworks de agentes ejecutan JS generado por el modelo en vm2 → inyección de prompt hacia RCE en el host
Corregido en	Versiones parcheadas de vm2 hasta la rama 3.11.x (verifique el aviso vigente antes de desplegar)
CVE de referencia	CVE-2026-22709, CVE-2026-24118, CVE-2026-24120, CVE-2026-24781, CVE-2026-26332, CVE-2026-26956, CVE-2026-43997, CVE-2026-43999, CVE-2026-44005 (e identificadores asociados de mayo de 2026)

Fechas clave: 26 de enero de 2026 — primer escape de 2026 divulgado. 4–7 de mayo de 2026 — conjunto de 10+ escapes. 7 de mayo de 2026 — análisis «prompts become shells» de Microsoft sobre el impacto a nivel de frameworks de agentes.

Este artículo cubre una clase de vulnerabilidad divulgada públicamente con fines defensivos y omite deliberadamente todo código de explotación funcional.