Una falla crítica de sandbox en vm2 permite que código no confiable escape al host

Los responsables de vm2, una biblioteca de sandbox para Node.js muy utilizada, han revelado una vulnerabilidad crítica que puede permitir que JavaScript no confiable escape de su sandbox y ejecute código en la máquina host. La falla está registrada como CVE-2026-26956, afecta a vm2 versión 3.10.4 y llega con código exploit de prueba de concepto ya disponible públicamente.

Esto importa porque vm2 es una de las herramientas estándar a las que recurren los desarrolladores cuando necesitan ejecutar JavaScript proporcionado por usuarios dentro de un entorno supuestamente restringido. Aparece en plataformas de programación en línea, productos de automatización, herramientas de AI y aplicaciones SaaS que permiten a los clientes ejecutar scripts. Cuando un escape de sandbox aparece en software como este, el problema no es una elegante falla teórica. Es una pregunta directa sobre si el código no confiable de un inquilino puede convertirse en un compromiso a nivel del host.

Según el advisory del mantenedor y el reporte de BleepingComputer, el bug está relacionado con la forma en que vm2 maneja las excepciones que cruzan entre el sandbox y el host. En la configuración afectada, el manejo de excepciones de WebAssembly puede eludir las protecciones de vm2 a nivel de JavaScript dentro del motor V8. Eso puede permitir que un objeto de error del lado del host vuelva a filtrarse al sandbox, donde los atacantes pueden abusar de la cadena de constructor para recuperar acceso a componentes internos de Node.js, como el process object, y finalmente ejecutar comandos arbitrarios en el host.

La exposición no es universal en todos los despliegues de Node.js. El advisory indica que el problema se confirmó en Node.js 25.6.1 en entornos con WebAssembly exception handling y soporte de JSTag habilitados. Ese alcance técnico importa, pero no debería generar una falsa sensación de seguridad. vm2 se descarga más de un millón de veces por semana en npm, y bibliotecas como esta a menudo quedan enterradas dentro de productos más grandes, herramientas internas o funciones de extensibilidad para clientes que los equipos no inventarían con suficiente cuidado.

El detalle más urgente es que el código exploit ya es público. Una vez que un escape de sandbox tiene tanto un CVE como una prueba de concepto pública, la distancia entre la divulgación y la explotación oportunista suele reducirse rápidamente, especialmente en servicios expuestos a internet que ejecutan workflows de usuarios, fragmentos de código o pasos de automatización. Si una empresa usa vm2 para aislar lógica no confiable, necesita asumir que los atacantes pondrán a prueba ese límite ahora, no después.

La ruta de patch es sencilla. Los usuarios deberían abandonar vm2 3.10.4 de inmediato y actualizar a la versión 3.10.5 o posterior, con la 3.11.2 disponible actualmente. Pero aplicar el patch por sí solo no es toda la respuesta. Los equipos también deberían identificar dónde está embebido vm2, confirmar si se están usando las configuraciones afectadas de Node.js 25 y revisar cualquier superficie del producto donde usuarios externos puedan enviar código que finalmente llegue a un sandbox de vm2.

Esta divulgación también encaja en un patrón más amplio. vm2 ha sufrido múltiples bugs graves de escape de sandbox en los últimos años, lo que plantea una pregunta de ingeniería difícil pero cada vez más importante: ¿cuánto aislamiento real ofrece un sandbox de JavaScript una vez que los atacantes empiezan a encontrar caminos alrededor de las defensas a nivel de lenguaje? Para los equipos que construyen plataformas sobre código ejecutado por usuarios, esa pregunta se está volviendo arquitectónica en lugar de incidental. Como informó primero BleepingComputer, la respuesta más segura aquí no es solo aplicar el patch rápido, sino volver a examinar cuánta confianza se está depositando en vm2 en primer lugar.