ChatGPT: un enlace bastaba para robar tu cuenta

Abrir un enlace compartido de ChatGPT bastaba para que un atacante ejecutara código dentro de la sesión autenticada de la víctima y leyera conversaciones privadas que nunca se habían compartido con él. El equipo de investigación de Parameter documentó la cadena completa, OpenAI la clasificó como P1 y la corrigió el 26 de octubre.

¿Qué encontró el equipo de Parameter en ChatGPT?

Parameter, un laboratorio de investigación en IA, publicó el detalle técnico de una cadena que convertía un enlace público de ChatGPT en JavaScript controlado por el atacante, ejecutándose dentro de la sesión autenticada de quien lo abría.

La víctima no tenía que instalar una app, unirse a un proyecto, pegar código ni abrir las herramientas de desarrollador. Bastaba con visitar el enlace compartido.

El payload no se limitaba a mostrar una alerta o modificar la página. Podía enumerar la lista de conversaciones de la víctima, recuperar el contenido de una conversación privada que nunca se había compartido con el atacante y enviar esos datos a un servidor externo. Como el código corría con el mismo contexto autenticado que la aplicación web, también podía llamar a las APIs de ChatGPT en nombre de la víctima. En la práctica: tomar el control de la cuenta.

El equipo reprodujo la ruta automática tres veces en una cuenta separada, incluso después de una recarga forzada, con la alerta apareciendo unos 4,5 segundos después de abrir el enlace.

¿Cómo se encadenaron tres fallos que parecían inofensivos?

El hallazgo no nació de una vulnerabilidad única, sino de la combinación de funciones que, por separado, parecían razonables.

• El sandbox de Preview funcionaba. El código dentro de Preview no podía leer parent.document, la página principal de ChatGPT. Ahí no había nada roto.
• Un gráfico cargaba MathLive. Una conversación con un gráfico interactivo normal cargaba la librería matemática MathLive, que instalaba en la página principal un listener para los mensajes relacionados con su teclado en pantalla.
• El listener no verificaba al remitente. MathLive aceptaba un mensaje que cambiaba el layout del teclado virtual, y ese layout podía contener HTML. Su controlador usaba una política de origen none: aceptaba mensajes de cualquier dirección web y no exigía que vinieran de una ventana previamente autorizada.
• El HTML llegaba a innerHTML. Cuando el teclado se abría, MathLive unía el layout recibido en un string HTML y lo asignaba a innerHTML en la página real de ChatGPT. Un helper llamado createHTML parecía sanitizar el valor, pero no lo hacía: marcaba el string como confiable y lo dejaba pasar sin cambios.
• El iframe sin sandbox. MathLive insertaba después un iframe con srcdoc y sin atributo sandbox. Eso creaba un documento nuevo donde un script externo podía ejecutarse y, como lo creaba la página principal de ChatGPT, heredaba la identidad https://chatgpt.com y podía acceder a la página padre.
• La CSP bloqueaba el JavaScript inline, pero permitía YouTube. La Content Security Policy de ChatGPT frenó el script inline, aunque autorizaba scripts de YouTube. El endpoint oEmbed de YouTube aceptaba un parámetro de callback estilo JSONP y colocaba ese callback en la respuesta antes de devolver su error de validación. Como YouTube ya estaba permitido por la CSP, el navegador cargó esa respuesta como script y ejecutó el callback dentro del nuevo frame.

Resultado: JavaScript arbitrario corriendo como chatgpt.com. El Preview original seguía aislado en su propia dirección web; el equipo cruzó la frontera convenciendo a un componente confiable de la página principal de crear un documento nuevo sin sandbox.

¿Por qué el vector era tan fácil de distribuir?

La primera versión del ataque no era realista: usaba una App de ChatGPT controlada por el investigador como remitente, y la víctima habría tenido que conectarla o invocarla primero.

El salto a un ataque práctico llegó al meter las dos piezas en una sola conversación pública normal:

• Un gráfico genuino que inicializaba MathLive en la página principal.
• Un HTML Preview generado por el asistente que enviaba los dos mensajes maliciosos.

El enlace resultante, del tipo /share/, conservaba la cadena completa para cualquier otro usuario. El atacante podía distribuirlo igual que distribuiría cualquier conversación compartida: por correo, chat, un ticket de soporte o una publicación en redes. La víctima solo tenía que visitar la URL.

¿Qué significa esto para tu startup?

Si tu producto tiene superficies compartibles —enlaces públicos, previews, embeds, widgets— este caso funciona como lista de tareas.

El punto central es que la seguridad no se mide por componente, sino por las costuras entre componentes. Cada pieza de ChatGPT era razonable por separado: Preview estaba aislado, los gráficos podían cargar un teclado matemático, los frames podían intercambiar mensajes, la CSP permitía un proveedor de medios grande y las conversaciones se podían compartir. La vulnerabilidad apareció solo cuando todo eso convivió en una misma página.

Acciones concretas que puedes implementar esta semana:

• Audita cada listener de postMessage. Verifica event.origin y event.source antes de aceptar cualquier mensaje que cambie estado. Un receptor que confía en el remitente equivocado convierte un sandbox en un pasillo.
• Prohíbe HTML crudo en configuraciones que cruzan ventanas. Si un componente acepta markup como dato de configuración, tienes una inyección esperando a que alguien la encadene.
• Mantén el atributo sandbox en todo documento creado dinámicamente cuando su contenido pueda venir de un frame no confiable.
• Trata la CSP como defensa en profundidad, no como la barrera principal. Aquí la CSP frenó el script inline y aun así el ataque encontró una puerta lateral en un dominio permitido.
• Prueba integraciones, no solo features. El bug vivía en la combinación de sharing público, Preview, una librería de terceros, creación de frames y CSP. Un test por feature aislado nunca lo habría encontrado.

Una nota sobre dependencias: MathLive es una librería de terceros. Si tu producto la usa o usa componentes similares, revisa si tu versión aplica las mismas mitigaciones.

¿Qué tan expuesta está la superficie de las apps de IA?

Este no es un caso aislado. WIRED reportó que OpenAI reconoció en su registro de cambios, el 25 de septiembre, un fallo ya corregido en la app de ChatGPT para macOS que podía permitir tomar el control de la aplicación en el equipo de la víctima y acceder a los historiales de chat y a sesiones de navegador. Lo encontró la Objective–See Foundation, y su analista Patrick Wardle lo describió como trivial de explotar, con una prueba de concepto de unas doce líneas de código, aunque solo era explotable por un atacante que ya tuviera malware instalado en el equipo objetivo.

La frase de Wardle resume el problema de fondo: los agentes necesitan mucho acceso para hacer su trabajo, son como el administrador de un edificio que tiene las llaves de todas las habitaciones, y si se corrompen el problema es enorme.

El contexto de escala tampoco ayuda. Según Engadget, OpenAI mostró en su evento para desarrolladores una cifra de 1.200 millones de usuarios semanales de ChatGPT, y la misma cobertura recoge que la compañía admitió que sus sistemas estuvieron involucrados en varios incidentes en los que se evadieron restricciones de sandbox. Más usuarios y más features significan más superficie expuesta.

¿Cómo respondió OpenAI?

El proceso de divulgación fue rápido, según el propio timeline publicado por Parameter:

• 18 de octubre: el reporte se envía al programa de bug bounty de OpenAI.
• 19 de octubre: se agrega la prueba de divulgación de un chat privado controlado.
• 21 de octubre: OpenAI reproduce el problema y la severidad sube de un triaje inicial P2 a P1.
• 22 de octubre: OpenAI reporta un frontend web corregido mientras el segundo seguía en actualización.
• 23 de octubre: cambios en la CSP bloquean parte de la cadena, aunque quedaba un frontend pendiente.
• 26 de octubre: OpenAI confirma que ambos frontends rechazan los mensajes de MathLive entre frames, marca el problema como resuelto y otorga un bounty total de 5.000 dólares.

Vale la pena mirar ese último número con calma. Un P1 que permitía tomar el control de cuentas y leer conversaciones privadas se pagó con US$5.000. Para un founder, la lectura no es criticar la cifra, sino entender la economía del otro lado: si tu producto depende de que investigadores externos encuentren fallos antes que los atacantes, el tamaño de tu recompensa determina cuántos ojos miran tu código.

Conclusión

La lección más útil de este caso no es técnica, es de proceso. El sandbox de ChatGPT no falló: falló la confianza entre componentes. Un receptor privilegiado aceptó instrucciones de un remitente que no había autenticado, y esa grieta alcanzó para saltar de un enlace público a la sesión privada de cualquier usuario.

Para un equipo pequeño, la prioridad es concreta: revisa tus listeners de mensajes, no dejes HTML crudo en configuraciones que cruzan ventanas y mantén con sandbox todo documento que crees con contenido de terceros. Cuesta una tarde de trabajo y elimina una clase entera de vulnerabilidades.

Y si construyes sobre plataformas de terceros, recuerda que la superficie compartible es input del atacante. Un enlace que compartes con confianza puede ser el vector.