WriteOut: cuando un sandbox de IA reenvía la cookie de sesión del usuario

¿Qué es esto?

El 7 de julio de 2026, el equipo de investigación de Sand Security divulgó un fallo crítico, ya corregido, de aislamiento de sesión en Writer, una plataforma de IA generativa para empresas. Lo llamaron WriteOut, y fue difundido el mismo día por The Hacker News. El fallo permite una toma de control de cuenta entre organizaciones «con un solo clic»: un atacante crea un agente en su propia cuenta, comparte el enlace de vista previa, y cualquier usuario de Writer que esté conectado y abra ese enlace puede ver su cuenta secuestrada, incluidos los administradores y usuarios de otras organizaciones.

El impacto es amplio. Una sesión robada de Writer da acceso a conversaciones privadas, documentos, configuraciones de agentes, modelos privados, conectores y credenciales de LLM almacenadas. Como el atacante y la víctima no necesitan pertenecer a la misma organización, el fallo rompe el aislamiento multiinquilino (tenant isolation) que los clientes empresariales asumen como base de un SaaS multitenant. Writer ya ha corregido el problema. Lo cubrimos porque la causa raíz es un error de diseño general: confiar a un sandbox gestionado una credencial de usuario que nunca debería haber visto.

Cómo funciona

El Framework de Writer ofrece una vista previa en vivo (live preview) para probar un agente durante su desarrollo. Esa vista previa ejecuta el código del agente dentro de un sandbox gestionado por Writer, al que se accede mediante un proxy de vista previa. El error estaba en cómo se autenticaba la petición hacia ese sandbox.

La cadena de explotación reportada, según Sand Security y The Hacker News:

1. El atacante crea un agente con vista previa en vivo y comparte su enlace público.
2. Una víctima conectada abre el enlace. Su navegador adjunta su cookie
   de sesión de Writer a la petición (same-site, está conectada).
3. El proxy de vista previa reenvía esa cookie al sandbox del ATACANTE.
4. El código del agente del atacante lee el token reenviado desde la memoria
   del proceso sandbox y lo envía a un servidor que él controla.
5. El atacante reproduce el token y controla la cuenta de la víctima.

El paso pivote es el n.º 3: la credencial de la víctima acaba dentro de un runtime totalmente controlado por el atacante. A partir de ahí, releerla es trivial: está en el proceso donde el atacante ya tiene permiso para ejecutar código.

Writer no estaba indefenso. Un filtrado de entrada intentaba bloquear las peticiones que leían variables de entorno o que enviaban código «obviamente malicioso». Pero esos controles inspeccionaban la instrucción, no el comportamiento en ejecución. Según Sand Security, la evasión consistía simplemente en no pegar la carga útil en línea, sino en pedir al agente que descargara y ejecutara un script remoto: el filtro veía una petición inofensiva de «descargar y ejecutar», y la lógica de explotación real nunca aparecía en el prompt. Es la lección de su artículo anterior “tu sandbox no es tu seguridad”: un sandbox que ejecuta código no confiable no es, por sí solo, una frontera de confianza.

Por qué importa

Las cookies de sesión son tokens al portador; cualquier cosa que pueda leer una se convierte en el usuario. Una cookie de sesión de Writer basta para ser la víctima. Reenviarla a un sandbox que ejecuta código proporcionado por el atacante le cede esa identidad por completo. No es un comportamiento exótico de la IA, sino un error clásico de alcance de credenciales, agrandado porque el sandbox es una funcionalidad diseñada para ejecutar, por definición, código de usuario arbitrario.

Las funciones de «vista previa» y «playground» de los agentes de IA son una superficie de ataque en rápido crecimiento. El patrón —dejar que el usuario escriba y ejecute al instante código de agente en un sandbox alojado— ya está en todas partes. Cada una de esas funciones es un lugar donde se ejecuta código no confiable cerca de las entrañas de la plataforma. Si cualquier secreto asociado al usuario (cookie, token de API, credencial de nube) es accesible desde ese runtime, una comodidad del producto se convierte en un compromiso entre inquilinos.

Un filtrado por prompt o por lista de permitidos que lee la intención no es un control en ejecución. La evasión trasciende el caso de Writer: un filtro que analiza la instrucción puede vencerse sacando la lógica maliciosa fuera de la instrucción («descarga y ejecuta esta URL»). El comportamiento debe restringirse donde se ejecuta —mediante límites de salida de red, aislamiento de memoria y mínimo privilegio— y no mediante la búsqueda de patrones en lo que el usuario escribió.

Defensas

El fallo concreto está corregido: Writer impide ahora por completo que la cookie de sesión del usuario se reenvíe a las vistas previas del sandbox, y sirve esas vistas previas desde un origen aislado. Las lecciones generales valen para cualquiera que construya funciones de vista previa o de ejecución de código de agentes.

1. Nunca dejar que una credencial de usuario entre en un runtime no confiable. Los sandboxes que ejecutan código de usuario o de terceros deben autenticarse con sus propios tokens efímeros y de alcance reducido, nunca con la cookie de sesión del usuario final. Retire y vuelva a emitir credenciales en la frontera.

2. Servir la ejecución no confiable desde un origen aislado. Coloque vistas previas, playgrounds y salidas de agentes renderizadas en un origen distinto (y un alcance de cookie distinto), para que las reglas same-site del navegador no adjunten las cookies de sesión de primera parte a esas peticiones. Es exactamente la corrección que aplicó Writer.

3. Imponer el comportamiento en ejecución, no la intención en la entrada. Asuma que los filtros de entrada serán evadidos por indirección (descarga remota, codificación, cargas por etapas). Controle lo que el sandbox puede hacer realmente: bloquee o ponga en lista de permitidos la salida de red, restrinja el acceso al sistema de archivos y a la memoria, y elimine las capacidades innecesarias.

4. Acotar y rotar los secretos del sandbox según el radio de impacto aceptable. Si un runtime debe contener un secreto, manténgalo por sesión, por inquilino y efímero, de modo que una fuga desde una vista previa no pueda reproducirse en otro lugar ni más tarde.

5. Tratar el aislamiento multiinquilino como un invariante probado. Los controles entre inquilinos deben estar en su conjunto de pruebas de seguridad: ¿puede un artefacto creado por el inquilino A hacer que se ejecute código —o que fluyan credenciales— en el contexto del inquilino B? Haga red team específicamente sobre las rutas de vista previa y de compartición.

Estado

Elemento	Referencia	Fecha	Notas
Divulgación de WriteOut	Sand Security	2026-07-07	Fallo crítico de aislamiento de sesión entre inquilinos en Writer
Cobertura independiente	The Hacker News	2026-07-07	Confirma la cadena de ataque y el impacto
Corrección del proveedor	Writer (vía Sand Security)	Reportado el 2026-07-07	Cookie ya no reenviada al sandbox; vistas previas movidas a un origen aislado

En una frase: un sandbox de IA gestionado recibió la cookie de sesión de la víctima, y una función pensada para previsualizar agentes se convirtió en una toma de control de cuenta con un solo clic, entre inquilinos. La lección duradera no atañe solo a Writer: un runtime diseñado para ejecutar código no confiable nunca debe recibir una credencial que identifique al usuario.