Escape de Sandbox Terrarium CVE-2026-5752 (CVSS 9.3): Lo que significa el error de Sandbox de Cohere AI para el aislamiento de contenido en stacks de Enterprise-Edge

8 Minutos de lectura · Fecha: 23.04.2026

El 14 de abril de 2026, CVE-2026-5752 se hizo público, una fuga de sandbox en el proyecto de código abierto Terrarium de Cohere AI. Desde el 22 de abril, los equipos de seguridad tienen una evaluación más precisa de la situación: CVSS 9.3, fuga de cadena de prototipos, ejecución de código root en el contenedor, posible ruptura hacia el host. Terrarium no es una herramienta de nicho, sino una infraestructura extendida para la ejecución de código en cargas de trabajo de LLM. Quienes en los últimos meses han construido funciones de IA con entornos de ejecución sandbox, se enfrentan a una pregunta urgente: ¿El bug también afecta a nuestro propio stack?

Lo más importante en resumen

• CVE-2026-5752 afecta al proyecto de código abierto Terrarium de Cohere AI, un entorno aislado (sandbox) para código generado por LLM y escrito por usuarios.
• El error reside en el aislamiento insuficiente de la cadena de prototipos de JavaScript. Los atacantes alcanzan el Function-Constructor y con ello globalThis.
• Impacto: Permisos de root en el contenedor, acceso a /etc/passwd y variables de entorno, acceso a la red en la red del contenedor, posible escape del contenedor.
• CERT/CC no pudo llegar a un acuerdo para la distribución coordinada de un parche con el proveedor antes de la publicación. La mitigación actual corresponde a los operadores.
• Los equipos de seguridad en stacks empresariales de edge deben aclarar en los próximos 14 días qué servicios utilizan Terrarium y qué capa de aislamiento hay detrás.

Qué es Terrarium y por qué el error es crítico

¿Qué es Terrarium? Terrarium es un entorno de pruebas (sandbox) de código abierto desarrollado por Cohere AI que se entrega como contenedor Docker. Ejecuta de forma segura código no confiable, como fragmentos de Python o JavaScript que son introducidos por los usuarios o generados por un Modelo de Lenguaje Grande (LLM). Terrarium es una de las implementaciones de referencia cuando los equipos de producto integran un intérprete de código en su aplicación de LLM, sin tener que construir una arquitectura de sandbox completa. Su uso abarca desde chatbots con ejecución de Python hasta agentes empresariales que realizan análisis de datos automatizados en entornos de clientes.

El error en sí es una variante de una clase de ataque conocida. El escape de la cadena de prototipos de JavaScript significa que el código cargado en la sandbox accede al objeto global a través de la propiedad Prototype del constructor Function. Terrarium genera un objeto Document simulado como un literal de objeto JavaScript normal. Este hereda a través de Object.prototype las funciones de acceso que los atacantes necesitan para escapar de la sandbox. Este patrón se conoce desde hace años en errores de sandbox de navegadores, pero en un contexto de ejecución de código en el lado del servidor con privilegios de Root, presenta una situación de riesgo diferente.

Las consecuencias prácticas son graves. Un exploit exitoso otorga privilegios de Root dentro del contenedor, lee o modifica /etc/passwd y las claves SSH, lee variables de entorno incluyendo claves de API, alcanza servicios vecinos en la red de contenedores y hace más probable las rutas de escape del contenedor. Dependiendo de la configuración, los accesos al host son posibles. Especialmente delicada es la combinación con claves de API de corta duración, que a menudo se pasan como variable de entorno. Un exploit puede extraer credenciales en cuestión de segundos, antes de que los equipos de seguridad reaccionen al incidente.

Por qué el error es estratégicamente más importante que un CVE individual

El valor del incidente no reside en el parche individual, sino en la pregunta que plantea. Los stacks de Edge empresariales han cambiado estructuralmente desde 2024. Muchos productos incluyen hoy una función de intérprete de código, donde usuarios o modelos de IA ejecutan pequeños scripts. El espectro de aplicación va desde asistentes de análisis de datos hasta flujos de trabajo autónomos que generan scripts por sí mismos. Una sandbox no es opcional en este contexto, sino el único puente entre la utilidad empresarial y un riesgo aceptable. Si el puente se rompe, se rompe toda la promesa.

Este mismo confianza es renegociado con un error Terrarium. Quienes utilicen Terrarium deben aclarar si su propio stack se ve afectado. Quienes utilicen otra sandbox, como Pyodide, E2B, nsjail, Firecracker-VMs o un desarrollo propio, deberían usar el error como motivo para una revisión de arquitectura. Los escapes de cadena de prototipo no son exclusivos de Terrarium. La pregunta es si la propia sandbox tiene una defensa sistemática contra esta clase de ataques o si contiene un error similar por otras razones.

Para los equipos de seguridad, esto significa concretamente: la arquitectura de sandbox será en 2026 un objeto de revisión propio, no un detalle secundario del framework. Quienes no hayan pensado su pipeline de producto de IA hasta la capa de ejecución de contenedores, están construyendo sobre arena. El error Terrarium es una desagradable oportunidad para darse cuenta de ello, antes de que lo haga un atacante.

Cómo es un plan de mitigación de 10 días

La duración se ha elegido deliberadamente corta. Los errores de sandbox con potencial de ejecución de código root exigen un ritmo claro. Quien exceda los diez días de tiempo de procesamiento, tiene un problema diferente a un CVE.

Lecciones estructurales para los equipos de seguridad del caso Terrarium

Dos lecciones merecen reflexión. La primera concierne la elección de la arquitectura de sandbox. Quien necesite una sandbox debería apilar al menos dos capas de aislamiento en 2026. Una sandbox de lenguaje como Terrarium o Pyodide es la primera capa. Un límite de contenedor duro o una Firecracker-Microvm es la segunda. En esta segunda capa, los bugs de cadena de prototipo pueden escapar, pero no tienen credenciales de producción ni acceso a red. Para cargas de trabajo sensibles, esta estructura de dos capas es lo mínimo indispensable.

La segunda lección concierne la relación con proveedores de proyectos de código abierto en el ecosistema de IA. Cohere es un proveedor comercial, mientras que Terrarium es un proyecto de código abierto con amplio campo de aplicación. CERT/CC no logró una distribución coordinada de parches. Esto no es inusual en proyectos que no están en el foco de los commits principales de un proveedor. Los equipos de seguridad deberían evaluar cada componente en su propia stack en función de qué tan confiablemente el proveedor reacciona en situaciones de emergencia. La brecha de Vercel a través de Context.ai OAuth del 22 de abril fue un ejemplo de un problema estructuralmente comparable en la cadena de suministro de la infraestructura de IA. Este patrón se repite más rápido de lo que el mercado puede solucionarlo.

Un tercer punto, menos considerado: las pruebas. Los bugs de sandbox de IA no se encuentran mediante escaneos clásicos de aplicaciones web. Se necesitan pruebas especializadas que prueben ataques de cadena de prototipos, trucos de herencia de objetos y variantes de escape. Las pruebas de penetración para productos de IA deberían incluir en 2026 una sección específica de sandbox. Quien compre pruebas basadas en el clásico OWASP Top-10 y crea que así está cubierta la aplicación de IA, está comprando una prueba incompleta. Quien incorpore este conocimiento en el próximo ciclo de pruebas, encontrará bugs antes de que la parte contraria los descubra.

Cómo traducir la resiliencia de sandbox a comunicación con el consejo de administración

Una parte del trabajo no se encuentra en la sala de servidores, sino en la sala de juntas. Cuando un miembro del consejo de administración pregunta si la organización se ve afectada por CVE-2026-5752, el nivel de dirección de TI (CIO) necesita una respuesta sólida. «Estamos revisándolo» no es suficiente. Una buena respuesta describe en tres frases qué servicios utiliza Terrarium, qué mitigación está activa y cuándo se tomará la decisión final. Quien pueda proporcionar esta estructura en 24 horas tiene una gobernanza de seguridad funcional. Quien no pueda hacerlo, sabe dónde debería invertirse en 2026.

Para el nivel de consejo de supervisión, merece la pena un segundo párrafo. No existe una seguridad completa en entornos de ejecución de código, pero sí existen clases de riesgo definidas y tolerancias a fallos aceptables. Una organización madura puede documentar su tolerancia a fallos y citar números de incidentes. Una organización inmadura habla de seguridad de manera abstracta, sin cifras. La reacción de Terrarium es un buen indicador de diagnóstico para determinar este grado de madurez.

Un último punto se refiere a las decisiones de personal. La seguridad de sandbox de IA es una especialidad que en 2026 hará que los talentos sean más escasos que la seguridad clásica de aplicaciones web. Quien contrate temprano a un ingeniero de seguridad senior con enfoque en sandbox o adquiera contratos de servicios gestionados, estará más preparado para el próximo incidente. La escasez en el mercado se intensificará en los próximos 18 meses, ya que más empresas integran funciones de IA en sus productos. Quien invierta ahora, asegurará conocimientos y recursos.

Qué podrían derivar los reguladores del caso Terrarium

La reflexión regulatoria merece su propia sección. El Reglamento de IA de la UE no aborda las pipelines de producción de IA a nivel de implementaciones individuales de sandbox. Sin embargo, exige para las aplicaciones de alto riesgo un gestión de riesgos sólida. Un error de sandbox sin parchar con CVSS 9.3 encaja en cualquier matriz de riesgos medianamente decente. Quien opere una aplicación de IA de alto riesgo en 2026 sin una revisión de sandbox documentada, estará acumulando un déficit de cumplimiento que saldrá a la luz en la primera ronda de auditorías en 2027.

Paralelamente, el ámbito de la NIS2 trabaja con principios similares. Los operadores de instalaciones esenciales y particularmente importantes deben adoptar medidas técnicas y organizativas adecuadas para proteger los sistemas de red e información. La arquitectura de sandbox entra en esta categoría. Una interpretación que entiende la ejecución de código de IA simplemente como una nueva clase de características es demasiado limitada. Tan pronto como un sandbox obtiene derechos de root en el contenedor y acceso a la red, se convierte en un sistema de red e información a efectos de la directiva.

Para los responsables de protección de datos, el caso abre otra discusión. Si los contenedores de sandbox tienen acceso a variables de entorno y destinos de red internos, los datos personales potencialmente están al alcance, incluso si la sandbox no accede formalmente a una base de datos. El artículo 32 del RGPD sobre medidas técnicas y organizativas adquiere una dimensión práctica a través de estos errores. Quien pueda documentar sin incidente qué datos fluyen a qué capa de contenedor, tiene una base sólida. Quien solo lo investigue después de un incidente se encontrará en una posición legal más delicada y tendrá que proporcionar justificaciones adicionales a las autoridades supervisorias y a su propia clientela, que nunca habrían sido necesarias antes del incidente.

La lección es pragmática: la documentación supera a la perfección. Un breve resumen de la arquitectura de sandbox con un párrafo por capa, un párrafo sobre flujos de datos y un párrafo sobre ciclos de parcheo es mejor que un informe perfecto que nunca se termina.

Preguntas frecuentes

¿Cómo puedo saber de forma fiable si mi aplicación utiliza Terrarium?

Buscar en SBOMs (listas de materiales de software), verificar imágenes de contenedor en busca de paquetes Cohere o Terrarium, y consultar directamente a los equipos de desarrollo. Herramientas automáticas de SCA (análisis de componentes de software) como Trivy, Snyk o Grype suelen encontrar la referencia de forma fiable, siempre que los SBOMs estén actualizados.

¿Cuáles son las alternativas a Terrarium que estarán establecidas en 2026?

E2B como sandbox empresarial con su propio modelo de aislamiento, Pyodide para escenarios de Python en el navegador, Firecracker-MicroVMs para una separación estricta de contenedores, nsjail para sandbox específicos de Linux y Wasmtime para aislamiento basado en WebAssembly. La elección depende del caso de uso y del perfil de rendimiento.

¿Es suficiente aislar solo el contenedor sin parchar la sandbox?

Solo si la segunda capa realmente es estricta, es decir, no hay credenciales de producción ni accesos de red amplios disponibles en el contenedor de la sandbox. En la práctica, la defensa en profundidad (Defense-in-Depth) es mejor: parchar o reemplazar la sandbox y fortalecer simultáneamente la capa del contenedor.

¿Qué dice CERT/CC sobre la falta de coordinación con el proveedor?

El boletín CERT/CC VU#414811 documenta el intento de contacto y la falta de disponibilidad del parche. Esto no es único en contextos de código abierto y obliga a los operadores a asumir su propia responsabilidad en la mitigación y la decisión sobre la continuación de las operaciones.

¿Cómo afecta el error a entornos multiinquilino?

Es especialmente crítico porque un atacante con acceso Root en el contenedor de la sandbox podría potencialmente alcanzar datos de otros inquilinos si el aislamiento es insuficiente. Los operadores multiinquilino deberían preparar de inmediato la comunicación con los clientes y realizar un análisis forense de los últimos 30 días.

¿Qué papel juega el monitoreo después de la mitigación?

Un papel central. Incluso si el parche o la mitigación surten efecto, permanecen las incertidumbres. Un monitoreo específico de actividades sospechosas en la sandbox, accesos a /etc/passwd y conexiones de egress inusuales en contenedores debería estar activo durante al menos 90 días.

Fuente imagen de portada: Pexels / cottonbro studio (px:5474025)

Sobre el autor: Benedikt Langer

Más artículos de Benedikt Langer