ChatGPT: un enlace compartido podía robar tu cuenta

Un enlace de ChatGPT bastaba para leer tus chats privados

Abrir un enlace compartido de ChatGPT podía ejecutar código en tu propia sesión y darle al atacante acceso a conversaciones privadas. La firma de seguridad Parameter Labs documentó una cadena de ataque completa contra la función de HTML previews (el patrón de artifacts que OpenAI llamó antes Canvas), donde apps HTML interactivas se muestran dentro de un iframe aislado.

Para un founder que ya usa ChatGPT para pegar contratos, código propietario o datos de clientes, la pregunta no es si el sandbox aguantó: es qué tan rápido se cierra un agujero que atraviesa la frontera entre el contenido no confiable y la sesión autenticada.

Qué encontró Parameter Labs en ChatGPT

El punto de partida es una función legítima: ChatGPT convierte un bloque de HTML dentro de un chat en una pequeña página web mediante el botón Preview. Como esa página puede contener cualquier código, se ejecuta en un frame bloqueado sobre una dirección web separada, sin acceso a la página principal de ChatGPT.

Leíste lo que hace la IA. ¿Y en tu negocio?

Un agente de IA puede quedarse con parte de tu día: ordenar lo pendiente y pedirte el OK antes de actuar. El Kit «tu mano derecha con IA» trae un video de 11 minutos y una ficha para dejar al tuyo trabajando. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Ese sandbox resistió. La entrada vino por una segunda función presente en la misma conversación: un gráfico interactivo. Dibujarlo cargaba MathLive, una librería JavaScript de matemáticas que incluye su propio teclado virtual y que dejaba activo un listener en la página principal de ChatGPT, a la espera de mensajes sobre ese teclado.

Según el análisis de Simon Willison, el código que recibía esos mensajes usaba innerHTML, así que cualquiera que enviara un mensaje podía inyectar HTML personalizado en la página padre. No existía ningún mecanismo que impidiera a otros frames aislados —incluidos los de HTML preview— invocar ese método.

La cadena de ataque, paso a paso

El recorrido que reconstruyó The Hacker News a partir del reporte de Parameter tiene cuatro eslabones:

El listener confiaba en cualquiera. MathLive actuaba sobre un mensaje que cambiaba su configuración sin verificar qué frame lo había enviado.
El mensaje podía llevar HTML crudo. Ese HTML se usaba como dato de configuración del teclado, no como texto plano.
El HTML creaba un frame sin sandbox. Aunque innerHTML no ejecuta etiquetas script directamente, sí permite inyectar un iframe nuevo sin restricciones, que el navegador trata como parte de chatgpt.com.
YouTube aportaba el código. La política de seguridad de contenido (CSP) de ChatGPT bloqueaba scripts en línea, pero permitía cargarlos desde unos pocos dominios, y uno era YouTube. El endpoint oEmbed de YouTube podía reflejar JavaScript de vuelta de una forma que sí se ejecutaba.

Con ejecución de JavaScript dentro de ChatGPT, el resto era directo: llamar a las APIs autenticadas del propio usuario y exfiltrar los datos mediante una referencia a una imagen.

El resultado práctico: se podía crear una URL de chat compartido que, al ser visitada por otro usuario con sesión iniciada, exfiltraba sus datos privados o ejecutaba acciones en su nombre. En la versión más fiable del ataque, la víctima solo tenía que abrir el enlace y pulsar una vez el botón Preview; en una variante posterior, la página abría el Preview sola.

Parameter aclara que fue una prueba controlada, ejecutada entre cuentas propias, y no reporta uso real del fallo.

Cuánto pagó OpenAI y por qué el monto genera debate

OpenAI cerró el agujero y pagó una recompensa de US$5.000. Willison califica ese monto como bajo para una vulnerabilidad de esta gravedad, y los números públicos le dan la razón.

Según el relevamiento de programas de bug bounty de IA de Wraith, el programa de seguridad de OpenAI paga entre US$200 y US$20.000, con hasta US$100.000 para hallazgos excepcionales. Su programa dedicado a seguridad de IA, lanzado en marzo de 2026 con un fondo anual de US$1 millón y gestionado vía Bugcrowd, eleva el techo a US$100.000 para hallazgos críticos y diferenciados.

El detalle importa más allá de la anécdota: The Hacker News reporta que Parameter reportó el fallo el 18 de octubre, que OpenAI lo reprodujo, subió la severidad de P2 a P1 —su categoría más seria— y desplegó el arreglo en dos versiones del frontend web. Para el 26 de octubre ambas versiones rechazaban los mensajes en los que se apoyaba el ataque, y el writeup se publicó el 28.

Es decir: la clasificación fue de máxima severidad, pero la recompensa quedó en el extremo bajo de la tabla pública. Ese desajuste entre severidad reconocida y pago es una señal relevante para cualquiera que evalúe dedicar tiempo a investigar seguridad de IA.

Por qué el sandbox no fue suficiente

La lección técnica es incómoda: el aislamiento funcionó, y aun así el ataque pasó. El problema no fue una sola falla, sino tres decisiones de diseño que se alinearon —un listener que no valida el origen, un canal que acepta HTML crudo y un HTML capaz de crear un frame sin sandbox que hereda la identidad del dominio principal.

El paso de YouTube era solo el último recurso, no la causa. Bloquearlo por sí solo habría dejado a un Preview no confiable con la capacidad de empujar HTML hacia el sitio principal. Eso es lo que convierte este caso en material de estudio para cualquier equipo que construya sobre iframes, postMessage o visores de contenido generado por usuarios.

Vale la pena leerlo junto a otro episodio del mismo año: Business Standard reportó que investigadores de Hacktron AI usaron Claude de Anthropic dentro del programa de bug bounty de OpenAI y lograron acceso a la cuenta de ChatGPT de un empleado y al repositorio privado de software, explotando una vulnerabilidad en Discourse, el software del foro comunitario. El patrón se repite: la superficie de ataque ya no está solo en el modelo, sino en todo el stack que lo rodea.

Qué significa esto para tu startup

Si tu producto embebe contenido de terceros, ejecuta HTML generado por usuarios o se comunica entre frames, este caso es tu checklist.

1. Valida el origen de cada mensaje, siempre. Si usas postMessage, verifica explícitamente el origin del remitente y nunca confíes en el contenido del mensaje por defecto. Un listener que acepta mensajes de cualquier frame es una puerta abierta, aunque el frame esté aislado.

2. Revisa tu CSP como si fuera un mapa de atajos. Permitir scripts desde dominios de terceros —YouTube, CDNs, widgets— abre caminos que no controlas. Audita qué dominios están en la lista y si alguno puede reflejar contenido ejecutable. Y si tu producto muestra HTML de usuarios, verifica que los iframes resultantes hereden el sandbox y no la identidad de tu dominio.

3. Trata el bug bounty como canal de confianza, no como gasto. Un hallazgo P1 reportado de forma privada te da tiempo para arreglar antes de que sea público. Si tu presupuesto de recompensas no refleja la severidad real de lo que te reportan, los buenos investigadores dejan de mirar tu producto.

Conclusión

El fallo de ChatGPT ya está cerrado y los usuarios no tienen que hacer nada: el arreglo vive del lado de OpenAI, sin instalar ni resetear nada. Lo que queda es la lección de arquitectura. La frontera entre contenido no confiable y sesión autenticada es frágil cuando varias piezas legítimas —una librería de gráficos, un botón de preview, una política de scripts— se combinan sin que nadie mire el conjunto.

Para un founder, la pregunta útil no es si tu sandbox aguanta, sino qué pasa cuando tres componentes que funcionan bien por separado se encuentran en la misma página.