Investigadores de ciberseguridad han dado a conocer una vulnerabilidad en isolated-vm que puede permitir a un atacante salir de los límites de una sandbox y afectar al proceso anfitrión. En sistemas donde se utiliza esta librería para ejecutar JavaScript no confiable, el fallo abre la puerta a corrupción de memoria y, en el peor de los casos, a la toma del control del host.
El problema se identificó como GHSA-864f-rcv7-6rh4 y, según la información disponible, todavía no se le ha asignado un identificador CVE. La corrección llegó en versiones específicas publicadas recientemente.
Qué es isolated-vm y por qué se usa
isolated-vm es una librería de Node.js pensada para ejecutar código JavaScript no confiable dentro de un entorno aislado. Su pieza clave es el uso de V8 Isolate: una instancia separada del motor JavaScript V8, con estado independiente.
La ventaja práctica es que se pueden ejecutar múltiples entornos sandbox de forma concurrente sin compartir datos ni interferirse directamente entre sí. Además, el aislamiento incluye memoria y estado propios, lo que hace que la arquitectura sea especialmente atractiva para aplicaciones que necesitan ejecutar código de terceros.
El rol de V8 Isolate y los límites de intercambio
Aunque cada Isolate mantiene su propio estado y heap, no es posible pasar objetos JavaScript de manera directa desde el hilo principal de Node.js hacia otro Isolate. Para resolver esa limitación, isolated-vm expone una clase llamada ExternalCopy, diseñada para serializar objetos desde el isolate del host y luego deserializarlos en el isolate invitado (guest).
En otras palabras: ExternalCopy es el “puente” encargado de mover datos de forma controlada entre límites de aislamiento.
La vulnerabilidad: fallo de tipo en ExternalCopy
El equipo de Endor Labs localizó el problema en el componente ExternalCopy. De acuerdo con la descripción técnica publicada, el fallo se relaciona con cómo se maneja una opción denominada transferList.
El resumen del impacto es claro: código que se ejecuta dentro de la sandbox puede provocar una corrupción de memoria en el proceso del host. La causa se describe como una confusión de tipos en la lógica de transferencia, que termina rompiendo la seguridad esperada al cruzar límites entre aislamientos.
De un fallo controlado a la desviación del flujo
Según el informe técnico, partiendo desde una referencia estándar (mencionada como ivm.Reference), el equipo consiguió escalar el fallo. El proceso descrito incluye pasar de una caída o crash en una dirección controlada a una situación más grave: la posibilidad de secuestro del flujo de control del host.
Esto es especialmente preocupante porque la capacidad de ejecutar dentro de la sandbox no debería, por diseño, permitir interferir en el proceso anfitrión más allá del intercambio de datos previsto.
Impacto real: corrupción de memoria, caídas y escape
El resultado de una explotación exitosa se centra en dos tipos de consecuencias:
- Corrupción de memoria en el proceso del host.
- Caída del proceso del host con un segmentation fault (SIGSEGV).
Además, los responsables advierten que el fallo también puede derivar en un escape de la sandbox “guest-to-host”. En términos de seguridad, eso significa que se erosiona la frontera de confianza que hace útil a isolated-vm.
El mantenedor del proyecto indicó que el impacto mínimo demostrado es un crash fiable (un denegación de servicio) que puede provocar cualquier “guest” que tenga acceso mediante una ivm.Reference. En el escenario máximo demostrado, el problema puede traducirse en secuestro del flujo de control del proceso host, que conceptualmente abre la posibilidad de ejecución remota de código en el host.
Versiones afectadas y parches disponibles
La vulnerabilidad afecta a todas las versiones de isolated-vm anteriores o iguales a la 7.0.0. El consejo operativo es actualizar cuanto antes a una versión que incorpore el parche.
En el anuncio se especifica que el problema fue corregido en:
- 6.2.0
- 7.0.1
Estas versiones fueron publicadas a principios de ese mismo mes, por lo que el rango de corrección está claramente delimitado.
Qué significa para la “aislación”: no todo estaba roto
Un punto importante del análisis es que la falla no recae en el aislamiento en sí. En la comunicación del descubridor se enfatiza que la frontera de V8 Isolate se mantuvo; lo que falló fue el “pegamento” en C++ que permite marshalling (el traslado) de valores a través del límite.
Dicho de forma sencilla: el bloque de construcción era sólido, pero la capa de integración que conecta ambos mundos introdujo una debilidad. Esta distinción suele ser clave porque ayuda a entender por qué el aislamiento sigue siendo válido como concepto, aunque la implementación concreta requiera parches.
Recomendaciones para usuarios
Si utilizas isolated-vm en entornos de desarrollo o producción para ejecutar JavaScript no confiable, la recomendación es actualizar a la versión más reciente disponible. En el material publicado se indica que actualizar a la última versión ofrece la mejor protección según el estado actual del proyecto.
También se menciona que ciertos detalles del exploit completo se mantuvieron en reserva para reducir el riesgo de que actores maliciosos puedan automatizar ataques de manera inmediata.
Preguntas frecuentes
¿Cualquier código dentro de la sandbox puede aprovechar el fallo?
El impacto mínimo demostrado se describe como activable por cualquier “guest” al que se le haya otorgado una ivm.Reference, que es el mecanismo estándar para conceder una capacidad a la sandbox.
¿El aislamiento de V8 Isolate deja de funcionar?
Según el análisis, la barrera de Isolate se mantiene. El problema está en la capa de transferencia y manejo de valores (ExternalCopy) que opera al cruzar el límite.
¿Se necesita esperar un CVE para actuar?
No. Aunque no se haya asignado todavía un CVE, la vulnerabilidad está identificada por GHSA-864f-rcv7-6rh4 y existen versiones corregidas. La acción recomendada sigue siendo actualizar a 6.2.0 o 7.0.1.
Conclusión
La vulnerabilidad en isolated-vm demuestra cómo un fallo en el intercambio de datos entre un entorno aislado y su host puede tener consecuencias serias: desde caídas por SIGSEGV hasta escenarios de escape y potencial secuestro del flujo de control. Si tu aplicación ejecuta JavaScript no confiable usando isolated-vm, el paso más importante es actualizar ya a las versiones corregidas.
Mantener el aislamiento como principio es esencial, pero igual de importante es vigilar que las capas de integración que conectan componentes también estén seguras y al día.
Fuente: https://thehackernews.com/2026/08/isolated-vm-flaw-lets-sandboxed.html
