Vulnerabilidad en isolated-vm permite corrupción de memoria y escape de sandbox

Investigadores de seguridad han revelado una vulnerabilidad crítica en la biblioteca open source isolated-vm —un binding de Node.js para ejecutar JavaScript no confiable en instancias aisladas del motor V8— que permite a código contenido en la sandbox corromper memoria del proceso anfitrión e incluso, en escenarios demostrados, escapar de la propia caja de aislamiento. El fallo, divulgado bajo el identificador de GitHub Security Advisory GHSA-864f-rcv7-6rh4, afecta a todas las versiones hasta la 7.0.0 incluidas y se ha corregido en las versiones 6.2.0 y 7.0.1 publicadas recientemente. El descubrimiento se atribuye a Cristian-Alexandru Staicu de Endor Labs y la corrección figura en el repositorio del proyecto en GitHub.

En términos técnicos confirmados, isolated-vm crea múltiples V8 Isolates —instancias separadas del motor V8 con heaps y estados independientes— para que aplicaciones Node.js puedan ejecutar código no confiable sin compartir objetos JavaScript directamente entre el proceso principal y los aislados. Para mover datos entre esos límites se emplea una capa de "pegamento" en C++ que serializa y deserializa valores; en esa capa la biblioteca expone la clase ExternalCopy, diseñada para copiar de forma segura objetos desde el host hacia el invitado y viceversa. Endor Labs documenta que la falla es una confusión de tipos (type confusion) en el manejo de la opción transferList de ExternalCopy, que permite a un invitado manipular estructuras internas y provocar corrupción de memoria en el proceso anfitrión.

Los efectos técnicos reproducidos por los investigadores incluyen, en el caso mínimo, un fallo controlado que provoca un SIGSEGV (denegación de servicio del proceso host) y, en el peor caso demostrado, la toma de control del flujo de ejecución del anfitrión, lo que abre la vía a ejecución remota de código en el proceso que aloja la sandbox. El mantenedor del proyecto, Marcel Laverdet, confirmó que el impacto mínimo es un crash reproducible por cualquier invitado que reciba un ivm.Reference —la forma estándar de otorgar capacidades a la sandbox— y que el impacto máximo demostrado fue un secuestro del control de flujo del host.

Es importante separar lo que está confirmado de lo que aún es incierto. Confirmado: la vulnerabilidad existe, ha sido reportada públicamente y parcheada en versiones específicas; el vector implica ExternalCopy y transferList; el potencial de corrupción de memoria y sandbox escape ha sido demostrado por los investigadores y descrito por los responsables del proyecto. Incertidumbres: no hay, hasta donde se ha reportado públicamente, evidencia de explotación masiva en entornos de producción; tampoco hay todavía un identificador CVE público asignado a la falla; y los detalles completos de la explotación han sido retenidos por los descubridores para evitar facilitar ataques.

El alcance práctico del problema depende de cómo se use isolated-vm en cada proyecto. La librería es popular en el ecosistema Node.js —su paquete en npm registró cerca de un millón de descargas en la última semana según métricas públicas— y se emplea tanto en servicios que permiten ejecución remota de scripts de usuarios, como en entornos de pruebas y herramientas de desarrollo. Quienes corran instancias de isolated-vm que acepten código no confiable o que otorguen ivm.Reference a invitados están en mayor riesgo, porque la capacidad mínima necesaria para explotar el fallo es precisamente disponer de esa referencia dentro del aislado.

Las consecuencias reales pueden variar desde indisponibilidades localizadas (procesos que se estrellan) hasta compromisos más graves del servidor o del servicio que hospeda la sandbox si una explotación consigue ejecutar código en el host. Además, la vulneración del límite de confianza entre huésped y anfitrión socava el principal propósito de usar isolates: ejecutar código potencialmente peligroso sin poner en riesgo el resto del entorno.

Recomendaciones prácticas y verificables para administradores y desarrolladores afectados: en primer lugar, actualice isolated-vm a una versión parcheada lo antes posible; los fixes están disponibles en el repositorio oficial y en npm. Puede comprobar e instalar la versión parcheada con comandos como npm ls isolated-vm --all para localizar dependencias, seguido de npm install isolated-vm@7.0.1 (o la versión mínima segura que su cadena de suministro requiera) y ejecutar npm rebuild si su entorno necesita recompilar módulos nativos. Consulte la página oficial del proyecto en GitHub para la nota de seguridad: GitHub Security Advisory y la entrada de npm: isolated-vm en npm.

Si no puede actualizar de inmediato, aplique mitigaciones temporales: evite entregar ivm.Reference a código de origen no fiable; minimice los privilegios del proceso que ejecuta las sandbox; encapsule cada sandbox en procesos separados con límites de recursos y políticas de sistema operativo (p. ej. usuarios sin privilegios, cgroups, seccomp, namespaces) para reducir el impacto de un crash o una ejecución arbitraria; y monitorice signos de explotación (crashes reiterados del proceso, comportamientos anómalos, logs fuera de lo común). Además, haga auditoría de dependencias transitorias con herramientas como Dependabot, Snyk o npm audit para identificar bibliotecas que arrastren isolated-vm.

Desde el punto de vista de diseño de software, este incidente recuerda que la seguridad de una sandbox no depende solo del aislamiento de V8 —los Isolates mantuvieron la frontera según los investigadores— sino también de la correcta implementación del código nativo que hace de puente entre límites de memoria. Como señala Endor Labs, una "primitiva sólida" (el límite de isolate de V8) puede quedar comprometida por errores en la capa de binding en C++.

Finalmente, acciones recomendadas a corto plazo para equipos de seguridad: priorizar el parche en despliegues expuestos, revisar la política de concesión de capacidades a sandboxes (evitar referencias cuando no sean estrictamente necesarias), configurar alertas por caídas de procesos y realizar una revisión forense de incidentes si se detectan signos de explotación. A medio plazo conviene reevaluar el modelo de ejecución de código no confiable —por ejemplo, mover cargas a procesos totalmente aislados a nivel de sistema o usar tecnologías de separación de privilegios más robustas— y mantener un canal de actualización automatizado para dependencias críticas. Para comprender cómo funcionan las Isolates a nivel de motor y por qué la capa de marshalling es tan sensible, puede consultarse la documentación de V8: V8 Isolates — v8.dev.

En resumen: existe un fallo comprobado en isolated-vm que permite corrupción de memoria desde sandboxes y ha sido corregido; la acción inmediata es actualizar y revisar la concesión de capacidades a invitados, mientras que la incertidumbre sobre uso en ataques reales requiere vigilancia y auditoría continua.