Se ha detectado un fallo crítico en ChatGPT que permitía a atacantes ejecutar código JavaScript controlado por ellos mismos en las sesiones de otros usuarios a través de conversaciones compartidas. Con solo abrir un enlace manipulado, el atacante podía robar datos, acceder a chats privados no compartidos y enviar dicha información a servidores externos. OpenAI ya ha solucionado este problema.

Un fallo crítico de ChatGPT permitía que una conversación compartida maliciosa ejecutara JavaScript controlado por un atacante en la sesión iniciada de otro usuario. El ataque podía listar chats privados, leer conversaciones que nunca fueron compartidas con el atacante y enviar datos robados a un servidor externo. En la demostración final, abrir un solo enlace manipulado fue suficiente.

OpenAI solucionó el problema el 26 de octubre de 2026, según la divulgación técnica de Parameter, publicada por Mukul Goyal el 28 de octubre. La empresa clasificó el informe como P1 y otorgó una recompensa de 5.000 dólares. El acceso a la cuenta demostrado se produjo a través de la sesión activa del navegador de la víctima, en lugar de una contraseña robada.

El exploit combinaba un gráfico interactivo con la función de Vista Previa HTML de ChatGPT. Normalmente, la Vista Previa ejecuta el código dentro de un marco restringido en una dirección web separada, evitando que lea directamente la página principal de ChatGPT. Ese límite funcionó inicialmente según lo previsto.

Fallo de ChatGPT explotado con un solo enlace

Sin embargo, el gráfico cargaba MathLive, una biblioteca matemática que añadía un receptor de mensajes a la página principal para su teclado virtual. A través de la interfaz postMessage del navegador, la Vista Previa aislada podía enviar instrucciones a ese receptor. MathLive aceptaba cambios de teclado sin verificar adecuadamente el origen del remitente ni requerir una ventana de origen aprobada.

Un mensaje suministraba una disposición de teclado que contenía HTML controlado por el atacante. Otro abría el teclado, colocando ese HTML en la página real de ChatGPT a través de innerHTML. Un ayudante llamado createHTML pasaba el contenido sin eliminar el marcado inseguro.

Esto difiere del fallo del sandbox de ChatGPT reportado anteriormente que exponía datos de Gmail, el cual utilizaba almacenamiento interno compartido. Aquí, el escape cruzó un límite del navegador a través de mensajes confiados por un componente de página privilegiado.

La inyección de HTML por sí sola no ejecutaba JavaScript inmediatamente. Los investigadores insertaron un iframe utilizando srcdoc, que almacena el HTML de una página incrustada directamente en un atributo. Debido a que este nuevo marco carecía de restricciones de sandbox, heredó el origen web de ChatGPT y pudo acceder a la página principal.

La Política de Seguridad de Contenido (CSP) de ChatGPT bloqueaba los scripts integrados pero permitía scripts de YouTube. Los investigadores descubrieron que el endpoint oEmbed de YouTube devolvía un callback JSONP suministrado por el atacante como JavaScript, incluso al informar de un callback inválido. Cargar esa respuesta proporcionó el paso final necesario para ejecutar código como chatgpt.com.

Luego, los investigadores colocaron tanto el gráfico como la Vista Previa HTML dentro de una conversación pública. Una versión anterior requería hacer clic en Vista Previa. La versión final la abría automáticamente y fue reproducida tres veces en una cuenta separada, apareciendo la ejecución después de aproximadamente 4,5 segundos.

Robo de chats privados y la solución de OpenAI

La carga útil leyó los detalles de la sesión ya disponibles para el frontend de ChatGPT y llamó a las APIs de conversación autenticadas. Recuperó una conversación privada no relacionada con el enlace compartido y luego envió un pequeño valor seleccionado a un servidor de investigación a través de una solicitud de imagen.

A diferencia del fallo del conector de GitHub de ChatGPT reportado por separado, este ataque no dependía de instrucciones de repositorio ni de herramientas conectadas. Su acceso provino directamente de JavaScript ejecutándose dentro del sitio web confiable.

Parameter envió el informe el 18 de octubre. OpenAI reprodujo el problema y aumentó su prioridad el 21 de octubre. Para el 26 de octubre, ambas versiones del frontend web afectadas rechazaban los mensajes de MathLive reportados. El caso resalta por qué los receptores cross-frame deben verificar tanto el origen del remitente como la ventana de origen, mientras que el HTML no confiable debe permanecer en un sandbox durante todo el renderizado.