Un fallo crítico de escape de SandboxJS permite la ejecución del código del host en las aplicaciones afectadas

Una vulnerabilidad crítica en SandboxJSpuede permitir que JavaScript controlado por un atacante escape del entorno limitado y ejecute código en el sistema host. La falla se rastrea como CVE-2026-43898 y afecta al paquete npm @nyariv/sandboxjs hasta la versión 0.9.5 inclusive.

La emisión tiene una puntuación CVSS 3.1 de 10,0, la calificación más alta posible.El aviso de GitHub dicela falla permite que el código de la zona de pruebas recupere una devolución de llamada en tiempo de ejecución interna, use valores falsificados, llegue al constructor de funciones del host real y ejecute JavaScript arbitrario fuera de la zona de pruebas.

Las aplicaciones enfrentan el mayor riesgo si usan SandboxJS para ejecutar JavaScript que no es de confianza o enviado por el usuario. Esto incluye herramientas de código en línea, plataformas de automatización, funciones de secuencias de comandos del lado del servidor, sistemas de complementos y cualquier producto que dependa de SandboxJS como límite de seguridad.

Qué afecta CVE-2026-43898

CVE-2026-43898 afecta a @nyariv/sandboxjs, una biblioteca de espacio aislado de JavaScript disponible a través de npm. Las versiones vulnerables incluyen todas las versiones anteriores a la 0.9.6.

La versión parcheada es 0.9.6. Los desarrolladores que utilizan la biblioteca deben actualizarla inmediatamente y revisar si algún JavaScript que no sea de confianza se ejecutó en las versiones afectadas antes de aplicar el parche.

GitHub publicó el aviso enGHSA-g8f2-4f4f-5jqw. La vulnerabilidad fue reportada por el investigador Macabely y está clasificada bajo CWE-94, control inadecuado de la generación de código.

Cómo funciona el escape SandboxJS

La vulnerabilidad se encuentra en la lógica de acceso a la propiedad registrada a través de addOps en prop.ts. Las versiones afectadas permitían que el código de espacio aislado accediera a propiedades de funciones confidenciales, como la persona que llama, la persona que llama y los argumentos.

En la compilación de CommonJS, este comportamiento permitía que el código de espacio aislado leyera Function.caller y filtrara una devolución de llamada interna privilegiada denominada LispType.Call. Esa devolución de llamada normalmente pertenece al tiempo de ejecución de SandboxJS y no debería estar disponible para código que no sea de confianza.

Una vez filtrada, la devolución de llamada podría invocarse con valores de objeto y contexto falsos controlados por el atacante. Esto le dio al atacante una ruta para recuperar las estáticas del host bloqueado y, en última instancia, llegar al constructor de funciones del host.

Por qué es importante el constructor de funciones del host

El constructor de funciones del host es peligroso en este contexto porque permite que el código JavaScript cree y ejecute código nuevo en el entorno del host. Si un script en el espacio aislado puede alcanzarlo, el entorno aislado ya no proporciona un aislamiento significativo.

La prueba de concepto en elEl aviso de GitHub demuestra el riesgo al ejecutar un sistemacomando a través de la funcionalidad incorporada de Node.js. Eso muestra que el ataque puede pasar de JavaScript en el espacio aislado a la ejecución de comandos a nivel de host dentro del proceso de la aplicación.

El impacto exacto depende de cómo se ejecuta la aplicación vulnerable. Si el proceso Node.js tiene acceso a archivos, variables de entorno, credenciales de nube, API internas o conexiones de bases de datos, un atacante exitoso también puede obtener acceso a esos recursos.

• Los atacantes pueden escapar de los límites de SandboxJS.
• Los scripts maliciosos pueden ejecutar JavaScript en el proceso del host.
• Las aplicaciones que ejecutan código enviado por el usuario enfrentan el mayor riesgo.
• Los secretos disponibles para el proceso del host pueden quedar expuestos.
• Los atacantes pueden modificar datos o interrumpir el servicio según los permisos del proceso.

Por qué la puntuación CVSS es 10,0

El aviso proporciona a CVE-2026-43898 un vector CVSS de AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Eso significa que la explotación puede ocurrir a través de una red en diseños de aplicaciones vulnerables, requiere una baja complejidad de ataque, no necesita privilegios y no requiere interacción del usuario.

El alcance se marca como modificado porque la explotación cruza el límite previsto entre el código de espacio aislado y el entorno host. Las calificaciones de impacto en confidencialidad, integridad y disponibilidad son todas altas.

Esto no significa que el paquete npm ataque los sistemas automáticamente después de la instalación. Significa que cualquier aplicación que exponga la zona de pruebas vulnerable a JavaScript controlado por un atacante puede convertirse en una ruta hacia la ejecución completa del código del proceso del host.

¿Qué aplicaciones enfrentan el mayor riesgo?

Las aplicaciones de mayor riesgo son aquellas que tratan a SandboxJS como un límite de seguridad para JavaScript que no es de confianza. Esto incluye servicios donde los usuarios pueden enviar scripts, fórmulas, complementos, automatizaciones, plantillas o fragmentos de código.

Las herramientas internas también pueden quedar expuestas.. Una plataforma de automatización del flujo de trabajo, un panel de administración, un sistema de prueba o una utilidad para desarrolladores aún pueden convertirse en un riesgo grave si un usuario con menos privilegios puede enviar JavaScript que se ejecuta a través de SandboxJS.

Los servicios de cara al público deberían recibir la atención más rápida. Si los usuarios no autenticados pueden proporcionar JavaScript a un tiempo de ejecución de SandboxJS vulnerable, la aplicación puede quedar expuesta a la ejecución remota de código sin credenciales.

Qué deberían hacer los desarrolladores ahora

Los desarrolladores deben actualizar @nyariv/sandboxjs a la versión 0.9.6 o posterior. Los equipos también deben reconstruir las implementaciones, actualizar los archivos de bloqueo y confirmar que los sistemas de producción ya no cargan versiones vulnerables.

Actualizar el paquete es el primer paso, pero los equipos también deben revisar los registros para detectar ejecuciones de scripts sospechosas. Cualquier sistema que haya procesado JavaScript que no sea de confianza a través de versiones afectadas debe tratarse como potencialmente expuesto.

Si la aplicación vulnerable maneja secretos, variables de entorno, tokens de API, credenciales de nube, contraseñas de bases de datos o datos de usuario, los equipos deben revisar si esos secretos eran accesibles para el proceso de Node.js y rotar las credenciales confidenciales cuando corresponda.

1. Verifique package.json y lockfiles para @nyariv/sandboxjs.
2. Actualice el paquete a la versión 0.9.6 o posterior.
3. Reconstruya y vuelva a implementar las aplicaciones afectadas.
4. Busque registros en busca de JavaScript enviado sospechoso o ejecución inesperada de procesos secundarios.
5. Revise si el proceso del host tuvo acceso a credenciales confidenciales.
6. Rote los secretos expuestos si no se puede descartar la explotación.
7. Deshabilite temporalmente la ejecución de scripts que no sean de confianza si la aplicación de parches no se puede realizar de inmediato.

Los desarrolladores que no puedan actualizar inmediatamente deben dejar de ejecutar JavaScript que no sea de confianza a través de las versiones de SandboxJS afectadas. Esta es la acción temporal más segura porque la falla rompe la promesa de aislamiento central de la biblioteca.

Los equipos también deben reducir los privilegios del proceso que aloja el sandbox. El proceso no debe ejecutarse como root o administrador, y no debe tener acceso amplio al sistema de archivos, a la red o a las credenciales.

Las bibliotecas de espacio aislado deben ubicarse dentro de controles en capas. Un entorno limitado de JavaScript no debería ser la única barrera entre el código que no es de confianza y la infraestructura confidencial.

• Deshabilite la ejecución de scripts públicos hasta que se implemente el parche.
• Ejecute el servicio con los privilegios más bajos posibles.
• Mueva la ejecución a un contenedor separado o a un trabajador aislado.
• Restrinja el acceso a la red saliente desde el host de la zona de pruebas.
• Elimine las variables de entorno y los secretos innecesarios del proceso.
• Aplique monitoreo para child_process, acceso a procesos y ejecución de comandos inusuales.

Por qué esto es un recordatorio sobre el riesgo del sandboxing de JavaScript

La zona de pruebas de JavaScript es difícil porque el lenguaje contiene muchas características reflexivas y dinámicas. Pequeños errores de exposición pueden crear rutas desde código restringido hacia objetos host, constructores, prototipos o devoluciones de llamadas internas.

SandboxJS también ha tenido varios anteriormente.avisos de escape de sandbox en 2026. Esa historia no significa que los desarrolladores deban evitar todas las bibliotecas de sandbox, pero sí muestra por qué los equipos deben evitar depender de una biblioteca como su único límite de seguridad.

Para cargas de trabajo de alto riesgo, los diseños más seguros aíslan la ejecución no confiable a nivel del sistema operativo o del contenedor. De esa manera, un escape de la zona de pruebas de JavaScript no se convierte inmediatamente en un compromiso amplio del host.

Preguntas frecuentes