MagnoSec Blog
Fallo en Isolated-vm Permite a JavaScript del Sandbox Escapar al Host: RCE en Plataformas que Confían en el Aislamiento
Isolated-vm: la librería que promete ejecutar JavaScript no confiable de forma segura y su fallo fundamental
Las plataformas serverless, los entornos de ejecución de código de terceros y los servicios cloud que permiten a los usuarios ejecutar JavaScript personalizado tienen un problema fundamental: cómo ejecutar código no confiable sin que comprometa el servidor. isolated-vm es una de las soluciones más populares a este problema. La librería crea máquinas virtuales V8 aisladas —instancias separadas del motor JavaScript de Chrome— con acceso restringido a la memoria, al sistema de archivos y a la red del proceso host. Cada VM aislada ejecuta el código de un cliente en un espacio de memoria separado, con su propio heap y su propio contexto de ejecución. En teoría, el código dentro de la VM no puede ver ni afectar al código fuera de ella. En la práctica, una vulnerabilidad en isolated-vm permite exactamente eso: escapar del aislamiento y ejecutar código en el proceso host. El fallo reside en el mecanismo de transferencia de datos entre la VM aislada y el host. Ciertos tipos de objetos JavaScript —específicamente, estructuras complejas con referencias circulares— no se serializan correctamente durante la transferencia, lo que permite a un atacante manipular la memoria del host desde dentro de la VM. El atacante puede entonces ejecutar código arbitrario en el proceso host, que típicamente tiene acceso a las bases de datos, los secretos y la infraestructura de la plataforma. Es la vulnerabilidad más temida en el mundo serverless: el escape del sandbox. Y isolated-vm la tenía.
Quién confía en isolated-vm: plataformas serverless, entornos cloud y ejecutores de código de terceros
El perfil de los usuarios de isolated-vm revela la gravedad del impacto. Plataformas de automatización que permiten a los clientes escribir scripts personalizados (Zapier, n8n, Huginn). Entornos de desarrollo cloud que ejecutan código de los usuarios (GitHub Codespaces, Gitpod, StackBlitz). Plataformas de funciones serverless que permiten código JavaScript de terceros. Servicios de generación de informes y documentos que ejecutan scripts de plantillas. Todos comparten la misma arquitectura de confianza: ejecutan código no confiable de múltiples clientes en servidores compartidos, confiando en que el aislamiento proporcionado por isolated-vm mantiene a los clientes separados entre sí y separados del host. Cuando ese aislamiento falla, el resultado es una brecha multi-tenant: un cliente malicioso puede acceder a los datos de todos los demás clientes que comparten el mismo servidor. Las plataformas que utilizan isolated-vm procesan datos de decenas de miles de organizaciones. Un escape del sandbox en uno de estos servidores expone los datos de todos los clientes alojados en él. La seguridad de isolated-vm no era un detalle de implementación: era el fundamento de la confianza de todo el modelo de negocio multi-tenant. Y ese fundamento tenía una grieta.
Así se escapa del sandbox: de la VM de V8 aislada al proceso host con RCE completo
La explotación del escape es técnicamente sofisticada. Fase 1: el atacante obtiene acceso a una instancia de isolated-vm —por ejemplo, creando un workflow malicioso en una plataforma de automatización que permite scripts personalizados—. Fase 2: el atacante ejecuta JavaScript dentro de la VM aislada que construye objetos con estructuras específicas —referencias circulares, proxies, getters con efectos secundarios—. Fase 3: el atacante pasa estos objetos a través de la frontera de transferencia de datos entre la VM y el host. La transferencia implica serializar los objetos en la VM y deserializarlos en el host. La vulnerabilidad está en la deserialización: ciertas estructuras de objetos no se validan correctamente, lo que permite al atacante manipular punteros de memoria en el heap del host. Fase 4: mediante la manipulación de los punteros, el atacante sobrescribe estructuras de control en el proceso host, redirigiendo la ejecución hacia código controlado por el atacante. Fase 5: el atacante ejecuta código nativo en el proceso host. Tiene acceso a los archivos del servidor, las variables de entorno (que contienen credenciales de bases de datos, claves de API, tokens de servicios cloud), y las conexiones de red del proceso. Fase 6: desde el proceso host comprometido, el atacante pivota hacia los sistemas conectados: bases de datos con los datos de todos los clientes, servicios cloud con las credenciales de la plataforma, sistemas internos de administración. La explotación requiere conocimiento profundo de la arquitectura de V8 y de isolated-vm, pero una vez desarrollado, el exploit es reutilizable y automatizable. Y en plataformas que ejecutan código de terceros, cualquiera puede ser el atacante —solo necesita crear una cuenta gratuita—.
El impacto: plataformas multi-tenant donde un solo escape compromete los datos de todos los clientes
El impacto de este escape se extiende a todo el ecosistema de plataformas que confían en isolated-vm. Cada plataforma afectada enfrenta la misma pesadilla: un cliente malicioso comprometió servidores compartidos y accedió a los datos de otros clientes. La respuesta es devastadora para el negocio: notificación obligatoria de brecha de seguridad a todos los clientes (bajo RGPD, con plazos de 72 horas y multas potenciales de hasta el 4% de la facturación anual), suspensión temporal del servicio mientras se investiga y se mitiga, pérdida de confianza de los clientes —que pueden migrar a competidores que prometen mejor seguridad—, y la reacción inevitable de los equipos de seguridad corporativos, que empezarán a exigir garantías de aislamiento que pocas plataformas pueden ofrecer de forma creíble. El coste reputacional de una brecha multi-tenant es existencial para una plataforma SaaS. Y la ironía es completa: las plataformas eligieron isolated-vm precisamente por su reputación de aislamiento robusto, frente a alternativas más simples como ejecutar JavaScript en un subproceso separado o en un contenedor Docker. La solución más robusta resultó ser vulnerable. La lección: ninguna capa de aislamiento es infalible. La seguridad multi-tenant debe diseñarse asumiendo que cualquier capa individual puede fallar. Y la defensa en profundidad —múltiples capas de aislamiento independientes— es la única arquitectura que sobrevive al fallo de una capa.
Cómo MagnoSec audita entornos serverless y ejecutores de código no confiable
En MagnoSec, las auditorías de plataformas serverless y ejecutores de código incluyen la evaluación de las capas de aislamiento y su configuración. Verificamos que isolated-vm —y cualquier otra librería de sandboxing— está en la última versión con todos los parches de seguridad aplicados. Evaluamos la arquitectura de aislamiento completa: ¿el sandbox de JavaScript es la única barrera entre el código del cliente y el host? ¿Hay aislamiento adicional a nivel de contenedor, de máquina virtual o de hardware? Analizamos la configuración del sandbox: ¿están limitados los recursos de memoria, CPU y tiempo de ejecución? ¿El acceso a la red desde el sandbox está restringido a una lista blanca? ¿El sistema de archivos del host es inaccesible desde el sandbox? Revisamos el proceso de despliegue: ¿los sandboxes se ejecutan en servidores dedicados por cliente o en servidores compartidos multi-tenant? ¿Hay segregación entre clientes a nivel de infraestructura? Simulamos ataques de escape del sandbox en entornos controlados para verificar que las defensas en profundidad funcionan. Y evaluamos el plan de respuesta a un escape: si el sandbox falla, ¿qué controles contienen el daño? ¿Cómo se detecta el escape? ¿Cómo se notifica a los clientes afectados? Un escape del sandbox es un escenario de pesadilla para cualquier plataforma multi-tenant. La única forma de dormir tranquilo es haber diseñado la plataforma asumiendo que el escape ocurrirá. Porque ocurrirá. La cuestión es cuánto daño hará cuando ocurra. Y esa respuesta se decide hoy, en la arquitectura, no mañana, durante el incidente.
Defensa: actualización de isolated-vm, defensa en profundidad y arquitecturas que no confían en un solo aislamiento
La defensa contra escapes de sandbox en plataformas multi-tenant se construye sobre el principio de defensa en profundidad. Cada capa de aislamiento puede fallar. La arquitectura debe sobrevivir al fallo de cualquiera de ellas. Capa 1: actualizar isolated-vm a la última versión con el parche que corrige la vulnerabilidad de deserialización. Esto es necesario pero no suficiente. Capa 2: ejecutar cada sandbox de cliente en un contenedor Docker separado con su propio namespace de red, su propio sistema de archivos y sus propios límites de recursos. Si el sandbox de JavaScript falla, el contenedor limita el daño. Capa 3: ejecutar los contenedores en máquinas virtuales separadas o en servidores dedicados para clientes de alto valor. La segregación a nivel de hardware es la capa más fuerte de aislamiento disponible. Capa 4: implementar el principio de mínimo privilegio para los procesos host. El proceso que ejecuta los sandboxes no debería tener acceso a las bases de datos de producción ni a los secretos de la plataforma. Utiliza arquitecturas de microservicios donde los sandboxes se ejecutan en procesos sin acceso a datos sensibles, comunicándose con los servicios de datos a través de APIs autenticadas. Capa 5: implementar monitorización de comportamiento para detectar escapes en tiempo real: patrones de uso de memoria anómalos, accesos a archivos fuera del sandbox, conexiones de red desde el proceso sandbox hacia destinos inesperados. Un escape del sandbox deja rastros. Hay que estar escuchando. La seguridad de las plataformas que ejecutan código no confiable no puede depender de una sola librería, por muy robusta que sea. La defensa en profundidad es la única arquitectura que ha sobrevivido a todos los escenarios de ataque. Y en el mundo de los sandboxes, la profundidad se mide en capas: cuantas más capas independientes de aislamiento tengas, menos probable es que un solo fallo comprometa todo el sistema.
Temas tratados
isolated-vm · sandbox · JavaScript · RCE · serverless · cloud · V8 · escape
Servicios relacionados
MagnoSec
Auditoría de Infraestructura
Auditoría de infraestructura tecnológica: redes internas y externas, servidores y firewalls. Hallazgos con CVSS y plan de remediación. PTES y OSSTMM.
MagnoSec
Pentesting Web y Hacking Ético
Pentesting web y hacking ético de aplicaciones y APIs según OWASP WSTG. Detectamos SQL Injection, XSS y fallos de autenticación. Informe con CVSS y remediación.
MagnoSec
Auditoría de Servicios Cloud
Auditoría de seguridad cloud en AWS, Azure y GCP. Revisión de IAM, almacenamiento, red, monitorización. Basado en CIS Cloud Benchmarks. Informe CVSS.
Servicios de auditoría
Pentesting Móvil y Auditoría de Apps
Pentesting de apps Android e iOS: análisis estático y dinámico, almacenamiento, comunicaciones y autenticación. Basado en OWASP MSTG, con informe y re-test.
Red Team y Simulación de Ataques Reales
Ejercicios Red Team con simulación realista de adversario. Basado en MITRE ATT&CK. Evaluamos detección, respuesta y contención. Incluye sesión Purple Team.
Auditoría de Active Directory
Auditoría de Active Directory: identificación de vectores de escalado, Kerberoasting, BloodHound, ACLs abusivas. Protege el núcleo de tu identidad corporativa.
Auditoría WiFi para Empresas
Auditoría de redes WiFi corporativas. War driving, rogue AP, WPA2/WPA3 Enterprise, 802.1X. Detectamos configuraciones débiles y accesos no autorizados.
Auditoría de Código Fuente
Auditoría de código de aplicaciones: revisión manual (code review) y SAST para detectar vulnerabilidades OWASP/CWE en cualquier lenguaje. Alcance y precio.
Auditoría de Seguridad para MVP y Startups
Auditoría de seguridad para MVP y startups: autenticación, control de acceso, APIs, Supabase/RLS y cloud. Revisión corta y priorizada antes de lanzar.
¿Quieres saber si tu empresa tiene estas vulnerabilidades?
Auditamos la seguridad de empresas de toda España con alcance cerrado por escrito, informe técnico y ejecutivo, y retest de las correcciones. Presupuesto en 24 horas y primera consultoría sin coste. Si no sabes por dónde empezar, haz el test de seguridad de 15 preguntas.
Artículos relacionados
agosto 2026
Fallo en KVM Rompe el Aislamiento de Virtualización Anidada y Permite a un Atacante Ejecutar Código como Root en el Host Linux
junio 2026
TrapDoor: La Campaña que Ataca Simultáneamente npm, PyPI y Crates.io para Robar Wallets, Claves SSH y Secretos Cloud
septiembre 2026
UTA0565 encadena dos zero-days de Chrome y Windows para instalar CLEANGULP
Recursos gratuitos
Guía completa
Guía de Pentesting Web: Metodología, Herramientas y Precios
Herramienta interactiva
Checklist de Seguridad Informática para Empresas
Referencia
Glosario de Ciberseguridad: 60+ Términos
Guía 2026
Certificaciones de Ciberseguridad: Precios y Comparativa
Herramienta
Calculadora de Precio de Pentesting
Cumplimiento
Pentesting para ISO 27001 y ENS: Qué Exige la Norma