Un enlace público compartido de ChatGPT puede ejecutar código de un atacante dentro de tu sesión iniciada. Esto es lo que se rompió de verdad, por qué importa a una empresa que funciona con IA y qué corregir esta semana.
Alguien te envía un enlace. Se parece a cualquier otra conversación compartida de ChatGPT que hayas abierto: el mismo dominio, el mismo diseño, un chat sobre una gráfica y un poco de HTML. Haces clic. Puede que incluso pulses el pequeño botón Preview por curiosidad.
Ese fue todo el ataque. Según la firma de investigación Parameter, ese único clic permitió que su código se ejecutara dentro de tu sesión autenticada de ChatGPT, con el mismo acceso que el sitio real. Desde ahí listó conversaciones recientes, abrió un chat privado que nunca se había compartido con nadie y envió parte de él a un servidor controlado por los investigadores. Su propio resumen es tajante: podían realizar cualquier acción en nombre de la cuenta de ChatGPT de la víctima.
Parameter reportó la falla a través del programa de bug bounty de OpenAI el 18 de octubre de 2026. OpenAI la corrigió el 26 de octubre y la calificó como P1, su categoría más grave. No hay evidencia de uso real y la prueba se ejecutó entre las propias cuentas de los investigadores. El parche ya está desplegado. El patrón, en cambio, no se va a ninguna parte.
Todo empezó con una gráfica y un teclado
Esta es la parte que conviene leer dos veces, porque explica por qué "ya parcheamos el error" nunca es el final de la historia.
ChatGPT puede convertir un bloque de HTML dentro de una conversación en una pequeña página web funcional gracias a su función Preview. Como esa página puede contener código arbitrario, OpenAI la ejecuta en un marco restringido y en una dirección web distinta. Por sí sola, esa separación aguantaba: el código dentro de la vista previa no podía leer la página principal de ChatGPT.
La conversación también contenía una gráfica interactiva normal. Detrás, la gráfica cargaba MathLive, una biblioteca de composición matemática. Cargarla hacía más que dibujar una curva: instalaba un listener en la página principal de ChatGPT para mensajes sobre el teclado en pantalla de MathLive.
Los navegadores llaman a esa API postMessage. Piénsalo como una ranura de correo entre dos marcos que, por lo demás, están sellados entre sí. Eso es seguro solo si quien recibe comprueba quién envía.
El listener de MathLive usaba una política de origen none, que es una forma educada de decir que aceptaba mensajes desde cualquier dirección web. El contenido que aceptaba actualizaba el diseño del teclado virtual, y ese diseño podía contener HTML. Cuando el teclado se abría, la biblioteca unía el diseño recibido en una cadena HTML y la asignaba a innerHTML en la página real de ChatGPT. Una función auxiliar llamada createHTML parecía sanear el valor. No lo hacía: marcaba la cadena como confiable y la dejaba pasar sin cambios.
Dos funciones sin relación entre sí. Un receptor confiable, instalado por una gráfica. Un emisor no confiable, suministrado por una vista previa. Un puente a través del sandbox.
De un mensaje perdido al acceso total a la cuenta
Las etiquetas de script insertadas mediante innerHTML no se ejecutan solas, así que los investigadores todavía necesitaban encender la mecha. Usaron un iframe con atributo srcdoc, insertado sin atributo sandbox. Eso creó un documento nuevo donde un script externo podía ejecutarse y, como el marco lo había creado la propia página principal de ChatGPT, el navegador le otorgó la identidad https://chatgpt.com. El código dentro de ese marco ya podía alcanzar la página padre.
La Content Security Policy de ChatGPT bloqueaba JavaScript en línea, que es exactamente para lo que sirve una buena CSP. Sin embargo, sí permitía scripts de YouTube. El endpoint oEmbed de YouTube aceptaba un parámetro de callback estilo JSONP y, muy útilmente, colocaba ese callback en su respuesta de error antes de validarlo. Como YouTube ya estaba en la lista de permitidos, el navegador cargó esa respuesta como script y ejecutó el callback del atacante dentro del nuevo marco.
Resultado: JavaScript arbitrario ejecutándose como chatgpt.com, dentro de una sesión iniciada y accesible mediante un enlace.
Parameter hizo entonces que la entrega fuera aburrida, en el mejor sentido para un atacante. Metieron la gráfica y la vista previa en una conversación pública normal, la exportaron como un enlace estándar /share/<id> y lo enviaron como cualquiera envía un chat compartido: por correo, en un mensaje, en un ticket de soporte, como publicación en redes. En la versión más estable la víctima pulsaba Preview una vez. En una versión posterior la vista previa se abría sola y la alerta saltaba unos 4,5 segundos después. Abrir el enlace era el único clic.
Sin instalación. Sin unirse a ningún espacio de trabajo. Sin pantalla de consentimiento. Sin página de phishing que casi parece real.
Por qué tu empresa debería preocuparse aunque ya esté parcheado
Es fácil archivarlo como "error de OpenAI, ya corregido, sigamos". Esa lectura se pierde las tres cosas que de verdad ponen en riesgo a tu organización.
Primero, la superficie de ataque era una función que te animan a usar. Compartir una conversación es una función de colaboración, y las funciones de colaboración suelen ser confiables por defecto. Aquí era un enlace que llevaba código ejecutable a una sesión autenticada.
Segundo, la frontera de confianza era la propia sesión de IA. Una vez que el código se ejecutaba, no necesitaba raspar píxeles de la pantalla: llamaba a las propias APIs autenticadas de ChatGPT como el usuario conectado. Cualquier control que vigile en qué hace clic una persona en la página no ve nada.
Tercero, un escape de sandbox en un producto rara vez es un fallo aislado. Esta cadena es un recorrido por atajos de desarrollo muy comunes: un listener de mensajes sin verificación del emisor, un saneador que marcaba la entrada como confiable en lugar de limpiarla, un iframe creado sin sandbox y una lista de permitidos de CSP lo bastante amplia como para ser útil a un atacante. Esos patrones existen en todos los proyectos que conectaron una integración con prisa. También en los nuestros.
La parte incómoda: tu sesión de IA es todo tu contexto
Pregúntate qué hay dentro de los chats de IA de tu equipo. La arquitectura de un cliente. Una cláusula de contrato reescribiéndose. Un plan de migración. Credenciales pegadas una vez y olvidadas. Un modelo de precios que alguien aún estaba decidiendo.
Eso no es un registro de chat. Es la concentración más densa de contexto de negocio que posees, y está protegida por una sola cookie de sesión que normalmente nunca caduca.
La lección no es "la IA es peligrosa". La lección es que las sesiones de IA merecen el mismo tratamiento que una consola de administración, no el mismo tratamiento que un cuadro de búsqueda.
Qué haríamos esta semana
- Tratar las sesiones de chat de IA como identidades privilegiadas. Exigir reautenticación, acortar la vida de las sesiones y requerir SSO con verificación de dispositivo donde el proveedor lo permita. Si la cookie de sesión puede leer toda la cuenta, debería caducar como una sesión de administrador, no como una web favorita.
- Eliminar las vistas previas automáticas y los enlaces sin revisar. Desactivar la vista previa automática del contenido compartido donde exista esa opción y explicar al equipo que un enlace inesperado es una carga maliciosa, no un gesto de cortesía.
- Registrar la capa de API, no la pantalla. Si tu monitorización solo ve actividad del navegador, es ciega a esta clase de ataque. Vigila las llamadas autenticadas a las APIs del propio producto de IA, con alertas de volumen y alcance.
- Minimizar lo que la sesión puede alcanzar. Separa cuentas personales y de empresa. Mantén el material confidencial de clientes fuera de los chats generales. Usa proyectos o espacios con permisos más estrictos cuando existan y borra lo que ya no necesites.
- Auditar tus propias integraciones buscando los mismos cuatro errores. Listeners
postMessagesin verificar, sumiderosinnerHTML, iframes sin sandbox y listas de permitidos de CSP más amplias de lo que la función necesita. Es una revisión de dos horas que se paga sola la primera vez. - Revisar las funciones de compartir del proveedor antes de activarlas. Pregunta qué puede hacer un artefacto compartido en la sesión de quien lo abre, no solo qué muestra.
La conclusión
El sector acaba de ver cómo un enlace público compartido se convertía en un mecanismo de entrega de código dentro de una sesión de IA autenticada, y el proveedor lo corrigió en ocho días, lo cual es un trabajo realmente rápido.
Lo que queda es la pregunta de diseño que todo equipo que construye sobre IA debe responder ahora: cuánto contexto guarda esta sesión, cuánto dura y qué puede ejecutarse dentro de ella.
En aratech construimos la infraestructura de IA sobre la que operan nuestros clientes, y esta es exactamente la costura a la que volvemos una y otra vez. Los agentes, copilotos y asistentes de chat no son complementos atornillados a tu stack: son componentes con identidad propia y con acceso a tu contexto más valioso. Trata la sesión como el activo que es y un enlace que llega en un ticket de soporte se convierte en una molestia en lugar de un incidente.
Si quieres un segundo par de ojos sobre hasta dónde llegan tus sesiones de IA, esa es la conversación que nos gusta tener.