Vulnerabilidad crítica en vm2 (CVE-2026-26956): rompe la sandbox y permite ejecutar comandos en el host con Node.js 25

Una falla crítica en la biblioteca de sandboxing para Node.js vm2 —registrada como CVE-2026-26956— permite a código malicioso escapar de la jaula y ejecutar comandos arbitrarios en el host. La vulnerabilidad ha sido confirmada al menos en la versión 3.10.4 y el mantenedor publicó un exploit de prueba de concepto, lo que convierte el hallazgo en una amenaza práctica para servicios que ejecutan código de terceros en tiempo real.

vm2 es ampliamente utilizada en plataformas de aprendizaje, editores en línea, automatizaciones y aplicaciones SaaS que aceptan y ejecutan scripts de usuarios, con más de 1.3 millones de descargas semanales en npm. La mecánica del fallo no es un clásico bypass de permisos en JavaScript: la librería confía en protecciones a nivel de JavaScript —envoltorios (Proxies) y saneamiento de objetos entre contextos— pero el manejo de excepciones a nivel de WebAssembly en V8 permite interceptar errores antes de que esas protecciones actúen. De acuerdo con la advertencia oficial, el vector explota la conversión símbolo→cadena para provocar un TypeError especialmente construido que hace que un objeto de error del lado del host "se filtre" al sandbox sin ser saneado; desde esa instancia corrupta los atacantes pueden recorrer la cadena de constructores y alcanzar internals como process, abriendo la puerta a ejecución remota.

Es importante subrayar que el mantenedor indica que el problema se ha reproducido en entornos con Node.js 25 (verificado en 25.6.1) cuando están activadas las funciones de manejo de excepciones de WebAssembly y JSTag. Sin embargo, dado que vm2 ha sufrido vulnerabilidades de escape de sandbox repetidas en años recientes, la aparición de exploits públicos y la complejidad del ecosistema V8 incrementan el riesgo de descubrimientos adicionales o de cadenas de explotación.

Las consecuencias prácticas para organizaciones que dependen de vm2 son claras: una explotación remota puede derivar en exfiltración de datos, acceso a secretos en memoria o disco, movimientos laterales desde servidores que ejecutan sandboxes, y además compromiso del pipeline de integración si estos entornos procesan código de terceros. El historial de vulnerabilidades previas en vm2 refuerza la necesidad de no confiar únicamente en controles de aislamiento implementados a nivel de lenguaje.

Para mitigar el riesgo de forma inmediata y pragmática, la recomendación directa es actualizar a vm2 versión 3.10.5 o superior (el mantenedor publicó la corrección en el repositorio; ver el aviso técnico en GitHub y las releases). Si no es posible aplicar el parche de manera inmediata, evaluar deshabilitar las funcionalidades de WebAssembly exception handling y JSTag en los entornos afectados, evitar ejecutar vm2 sobre Node.js 25 hasta confirmar la configuración segura, o eliminar temporalmente la ejecución de código sin revisar. La página del mantenedor contiene tanto la advisoria con detalles técnicos como los artefactos de la release 3.10.5 que corrigen la falla.

Más allá del parche, conviene aplicar principios de reducción de superficie y defensa en profundidad: correr sandboxes en procesos aislados con mínimos privilegios del sistema operativo, contenerlos con contenedores o VMs dedicadas, aplicar controles de red y políticas de egress estrictas, usar mecanismos de control de recursos (cgroups, límites de CPU/memoria) y minimizar la exposición de secretos en los entornos de ejecución. También es recomendable instrumentar detección y respuesta a comportamientos anómalos (ejecución de comandos del sistema, acceso a rutas sensibles) y rotar credenciales que puedan haber sido accesibles desde sandboxes comprometidos.

Para equipos de desarrollo y seguridad que gestionan dependencias, conviene auditar dónde se usa vm2 dentro de repositorios y pipelines, fijar versiones en el gestor de paquetes, añadir comprobaciones de seguridad en CI para detectar y bloquear versiones vulnerables, y coordinar pruebas de vulnerabilidad incluyendo el análisis del PoC publicado para comprender el alcance en su entorno. Dada la rapidez con la que aparecieron exploits públicos, asumir un modelo de responsabilidad compartida entre maintainers y consumidores es esencial.

Este incidente subraya dos lecciones: primero, que lograr un aislamiento robusto en entornos JavaScript es complejo y frágil cuando interactúa con capas más profundas del motor de ejecución; y segundo, que las organizaciones no deben depender solo de sandboxing a nivel de lenguaje para ejecutar código no confiable. Mantener las dependencias actualizadas, aplicar parches con rapidez y adoptar medidas de contención adicionales son las acciones que reducen significativamente el riesgo hasta que se pueda rehacer la arquitectura de ejecución con controles más sólidos.