La acción de la víctima completa era una: abrir un link. Un enlace de una conversación de ChatGPT compartida, de esas que mandan por WhatsApp, por correo o pegan en un ticket de trabajo todos los días. Si la conversación la había preparado un atacante, su código javascript corría dentro de tu sesión ya autenticada en chatgpt.com, podía enumerar tus conversaciones, leer chats privados que nunca habías compartido con nadie y mandar ese contenido a un servidor externo. Sin instalar nada, sin pegar código, sin aceptar permisos raros.
Cómo se cruzó la muralla
Lo investigó el equipo de Parameter y el detalle que me quedó pegado es que el agujero no estaba en una sola función vulnerable, sino en la costura entre dos features que por separado eran seguras. Un gráfico interactivo cargaba una librería de matemáticas (MathLive) que instalaba un listener de postMessage en la página principal. Ese listener aceptaba mensajes de cualquier origen y uno de esos mensajes incluía HTML, que terminaba en un innerHTML. El HTML Preview del chat, que corre aislado en otro dominio, era justo el emisor que nadie esperaba: le lanzó los mensajes al listener del gráfico y quedó el HTML inyectado en la página real de ChatGPT.
Ahi el script todavía no ejecutaba, por dos capas que parecían sólidas. Primero, un iframe con srcdoc sin atributo sandbox, que hereda la identidad de chatgpt.com y permite que el script nuevo ejecute. Segundo, la CSP de la página: correcta, pero permitía scripts de YouTube, y el endpoint de oEmbed de YouTube inyectaba el callback del atacante en la respuesta JSONP incluso cuando lo estaba rechazando por inválido. CSP blindada, tercero confiado. Con el javascript corriendo como chatgpt.com, el payload sacó el token de sesión del documento y llamó directo a la API interna como si fuera el propio cliente web. La exfiltración fue un simple request de imagen.
OpenAI lo corrigió el 26 de octubre y lo clasificó P1. Nadie fue hackeado masivamente que se sepa, pero la ventana existió, y el exploit completo era un link común y corriente. Nadie desconfía de un chat compartido: ese es el problema.
Lo que me gusta y lo que me preocupa
Me gusta porque es un hallazgo honesto y bien documentado: reporte, corrección, writeup con todos los detalles. Me preocupa porque el patrón es el mismo que llevo años viendo cuando uno arma sistemas: cada pieza responde «yo estoy aislada» y nadie revisa las uniones. Yo ando armando integraciones con iframes, webhooks y listeners de mensajes, y es muy fácil pensar que el aislamiento del frame ya es la seguridad. No lo es: la muralla es tan fuerte como el puente más descuidado que la cruza.
Si construyes algo con frames o widgets embebidos, tres reglas baratas que salen de este caso:
Valida origen y fuente en cada mensaje. Un listener de postMessage sin chequear event.origin y event.source es un buzón abierto para todo el vecindario.
Toda superficie compartible es input del atacante. Un link de share, un embed, un preview exportado: trata esa URL como código hostil hasta que demuestre lo contrario.
La CSP no arregla un camino inseguro. Es defensa en profundidad, no el muro. Y cada dominio de tercero en la allowlist (YouTube, analytics, lo que sea) es una puerta que alguien puede usar de trampolín.
Yo me revisé mis propios proyectos con esta lupa después de leer el reporte: ¿qué listener de mensajes tengo corriendo en una página autenticada y de quién acepta mensajes? La respuesta rápida suele ser incómoda.
Y la próxima vez que llegue por WhatsApp un link de conversación de ChatGPT compartida, no es paranoia: hasta hace pocos días, abrirlo podía entregar tu cuenta entera.
Fuente del tema: Do the Math: How We Took Over ChatGPT Accounts, del laboratorio de Parameter.
Fuente de inspiración: Do the Math: How We Took Over ChatGPT Accounts (Parameter)
