Un enlace compartido de ChatGPT podía ejecutar código malicioso y leer chats privados

Un solo enlace para compartir de ChatGPT — de los que se pegan a diario en correos, tickets de soporte y redes sociales — bastaba para ejecutar el código de un atacante dentro de la sesión de quien lo abriera. Desde ahí, el código podía listar las conversaciones recientes de la víctima, abrir un chat privado que nunca se había compartido y enviar su contenido a un servidor externo. OpenAI ya ha corregido el problema y los usuarios de ChatGPT no necesitan hacer nada.

Qué ocurrió

El fallo se reportó a través del programa de recompensas por errores de OpenAI el 18 de octubre y se corrigió ocho días después. OpenAI reprodujo tanto la ejecución de código como el acceso a los chats privados, elevó la gravedad de P2 a P1 — su categoría más seria — y desplegó la corrección en dos versiones del front-end web de ChatGPT. El 26 de octubre, ambas versiones ya rechazaban los mensajes de los que dependía el ataque. Se pagó una recompensa de 5.000 dólares.

La demostración fue una prueba controlada entre cuentas separadas. No hay constancia de que la técnica se haya usado contra usuarios reales.

Cómo funcionaba el ataque

El cebo era una conversación compartida de aspecto normal. La víctima no tenía que instalar nada, iniciar sesión a través del atacante ni unirse a un espacio de trabajo. En la versión más fiable, abría el enlace y pulsaba una vez el botón Preview de ChatGPT; una variante posterior abría la vista previa automáticamente, de modo que bastaba con visitar el enlace.

El ataque encadenaba tres decisiones de diseño que, por separado, parecían inofensivas:

1. Una vista previa aislada. ChatGPT puede mostrar un bloque de HTML de un chat como una pequeña página web. Esa vista previa se ejecuta en un marco aislado, en otra dirección web, y no puede leer la página principal de ChatGPT. Ese aislamiento resistió.
2. Un listener demasiado confiado. El mismo chat incluía un gráfico interactivo que cargaba la biblioteca MathLive en la página principal de ChatGPT. MathLive dejaba activo un listener para mensajes sobre su teclado en pantalla, sin comprobar qué marco los enviaba.
3. HTML dentro de un «diseño de teclado». Esos mensajes podían transportar HTML sin filtrar como datos de diseño de teclado. Así, la vista previa aislada podía enviar un mensaje a través del límite entre marcos y conseguir que su HTML se insertara en la página principal, de confianza.

Ese HTML inyectado creaba un nuevo marco sin aislamiento que el navegador trataba como parte de chatgpt.com. La política de seguridad de contenido bloqueaba los scripts en línea, pero permitía scripts servidos desde YouTube, así que la carga final se obtenía desde allí. Ejecutándose con todo el acceso web de la víctima, el código llamaba directamente a las API autenticadas de ChatGPT, por lo que su alcance iba mucho más allá de lo que hubiera en pantalla. En principio, podía actuar en nombre de la víctima en toda la cuenta.

El paso por YouTube fue solo un rodeo para esquivar la política de seguridad, no la causa raíz. Bloquearlo por sí solo habría dejado una vista previa no fiable capaz de inyectar HTML en el sitio principal.

Por qué importa

Los asistentes de IA guardan cada vez más material sensible: código fuente, contratos, datos de clientes, planes internos. Un enlace compartido es un formato de confianza y fácil de abrir, y este caso muestra cómo una función pensada para la comodidad puede convertirse en un vector de ataque. También es un ejemplo de manual de cómo un buen aislamiento puede quedar anulado por un componente de terceros situado al otro lado del muro: bastó un único manejador de mensajes sin verificación de origen.

Qué hacer

• Usuarios de ChatGPT: no hay nada que instalar ni restablecer: la corrección es del lado de OpenAI. Aun así, desconfíe de chats compartidos por remitentes desconocidos y evite pulsar Preview en contenido que no le inspire confianza.
• Organizaciones que usan asistentes de IA: traten el historial de chats como datos sensibles. Definan qué se puede introducir en ellos y revisen qué cuentas e integraciones tienen acceso.
• Equipos web y de producto: auditen cada listener de postMessage en su propio código y en las bibliotecas incluidas. Validen el origen del remitente, no acepten nunca HTML sin filtrar por un canal de mensajes y consideren cualquier script de terceros permitido por su política de seguridad de contenido como parte de su superficie de ataque.

Este tipo de fallos vive en las uniones entre componentes: un listener en una biblioteca, una excepción de política en otra. Es justo la clase de problema que nuestra revisión de código asistida por IA está diseñada para detectar: sigue cómo circulan los datos no confiables por el front-end y las dependencias, y señala verificaciones de origen ausentes e inserciones de HTML inseguras antes de que lleguen a producción.