Una imagen subida a un foro de ayuda fue el punto de partida del hackeo a OpenAI que comprometió cuentas de ChatGPT y Codex de empleados y permitió demostrar acceso a código interno de la compañía. Tres especialistas de Hacktron AI explicaron cómo combinaron dos vulnerabilidades y utilizaron modelos Claude de Anthropic para realizar parte del trabajo técnico.
El ataque ocurrió el 25 de julio de 2026 y tomó menos de 72 horas desde el descubrimiento inicial hasta la prueba de acceso, según el equipo. Una vulnerabilidad en un servicio conectado terminó abriendo el camino hacia cuentas que podían tener integraciones con GitHub, Slack, Outlook, Gmail y Google Drive.
El hackeo a OpenAI comenzó con una imagen HEIF
El foro community.openai.com funciona sobre Discourse, una plataforma de código abierto. Los archivos HEIC y HEIF, formatos diseñados para almacenar imágenes de buena calidad ocupando menos espacio, seguían una ruta particular. Discourse los enviaba a ImageMagick, un programa para procesar y convertir fotografías, que utilizaba un componente llamado libheif para interpretarlos.
Ese componente contenía un error de memoria que podía aprovecharse mediante un archivo manipulado. La corrección ya existía en el proyecto original desde el año anterior, pero no había sido identificada como una actualización de seguridad. El equipo considera que esta situación pudo contribuir a que algunas versiones de Debian, el sistema operativo utilizado como base por Discourse, continuaran distribuyéndolo sin el parche.
A partir de ese fallo, los especialistas consiguieron ejecutar instrucciones en el servidor que alojaba el foro. En términos sencillos, lograron que el sistema realizara acciones que normalmente no debería permitir a una persona externa. La vulnerabilidad recibió una gravedad de 8,8 sobre 10.
El aviso de seguridad identifica el problema como CVE-2026-32882, el código utilizado para registrar públicamente una vulnerabilidad conocida. El documento confirma que podía activarse durante la carga y el procesamiento de imágenes.
Claude intervino en esta fase. Según el reporte, Opus 4.8 detectó que faltaban correcciones de seguridad y ayudó a desarrollar un método inicial para aprovechar el error. Opus 5 consiguió después adaptar ese procedimiento al entorno utilizado por la plataforma.
Un fallo de inicio de sesión abrió el camino a ChatGPT y Codex
Acceder al foro fue solo el primer paso. La segunda vulnerabilidad estaba en el sistema de inicio de sesión único de OpenAI, que permite utilizar una misma identidad para entrar a diferentes servicios. Esa debilidad hizo posible pasar del entorno comprometido a cuentas de ChatGPT y Codex.
Las consecuencias podían aumentar cuando esas cuentas tenían otras plataformas conectadas. Según el reporte, las integraciones podían incluir Outlook, Gmail, Google Drive, Slack y GitHub. Esto no significa que todas fueran consultadas durante las pruebas, sino que podían quedar al alcance dependiendo de las conexiones habilitadas en cada cuenta.
Ambas vulnerabilidades formaron una misma cadena. La primera permitió entrar al foro y la segunda extendió el acceso hacia otros servicios asociados con las cuentas afectadas.
Codex permitió demostrar el acceso al código interno
Una de las cuentas comprometidas pertenecía a un empleado que tenía Codex conectado con la organización de OpenAI en GitHub. Para comprobar los permisos obtenidos sin consultar información sensible, los especialistas pidieron a la herramienta que abriera una pull request, una solicitud utilizada para proponer cambios en el código de un proyecto.
La solicitud #1186742 quedó registrada en el espacio interno openai/openai. Los responsables de la investigación aseguran que no leyeron código sensible y detuvieron las pruebas después de demostrar que podían interactuar con ese entorno. Por esta razón, describir el episodio como un robo de código privado iría más allá de lo documentado.
El hackeo a OpenAI fue reportado el 25 de julio mediante Bugcrowd, una plataforma utilizada por empresas para recibir informes sobre vulnerabilidades. La compañía confirmó la corrección del fallo de inicio de sesión unas 14 horas después del primer aviso, según la cronología publicada.
Discourse recibió por separado la información relacionada con el procesamiento de imágenes. La empresa respondió al día siguiente y tenía preparada una solución el 27 de julio. OpenAI pagó posteriormente US$6.500 por el hallazgo relacionado con sus sistemas y el caso fue marcado como resuelto el 1 de septiembre.
La recompensa requiere una precisión. Las pruebas realizadas sobre community.openai.com, alojado por Discourse, estaban fuera del alcance del programa de recompensas de la compañía. Los US$6.500 correspondieron al hallazgo relacionado con sus propios sistemas y no a las acciones efectuadas contra el foro.
Claude hizo en horas parte del trabajo técnico
Opus 4.8 consiguió desarrollar un método que funcionaba cuando estaba desactivada una protección que cambia la ubicación de determinados datos en la memoria para dificultar los ataques. Cuando esa barrera estaba activa, los intentos no funcionaban de manera fiable.
Horas después del lanzamiento de Opus 5, una nueva sesión produjo en aproximadamente tres horas un método funcional en una Mac utilizada para las pruebas. Después, los especialistas consiguieron adaptarlo al sistema empleado por Discourse y comprobaron que podían ejecutar instrucciones mediante la carga de un archivo.
Otra prueba utilizó el modelo contra una instalación propia de Discourse Cloud. Claude se negaba a desarrollar el ataque contra sistemas remotos, según el relato publicado. Para continuar, los especialistas prepararon un entorno controlado que simulaba una competencia de seguridad informática y allí completaron el procedimiento.
La intervención humana siguió siendo necesaria. Los especialistas eligieron los objetivos, prepararon los entornos, supervisaron los resultados y decidieron cómo avanzar. Aun así, atribuyen a los modelos una parte considerable del trabajo técnico y consideran que estas herramientas pueden reducir el tiempo y los conocimientos especializados necesarios para desarrollar ataques complejos.
La investigación fue más allá del caso OpenAI
El trabajo formaba parte de un proyecto denominado HEIF Heist. Durante dos meses, tres especialistas estudiaron vulnerabilidades relacionadas con el procesamiento de imágenes en servicios y proyectos como Slack, Meta, GitHub Enterprise, Ruby on Rails, Next.js, Astro y Gatsby.
Según los autores, adaptar el método a cada objetivo requería generalmente entre uno y dos días y todo el proyecto costó menos de US$3.000 en uso de modelos de inteligencia artificial. Estos datos corresponden al reporte del equipo y no significan que todas las plataformas mencionadas sufrieran el mismo nivel de exposición encontrado en este caso.
La experiencia llevó a sus responsables a advertir que la IA puede reducir parte del conocimiento especializado y del tiempo necesarios para convertir una vulnerabilidad en un ataque funcional. La supervisión humana, sin embargo, continuó siendo necesaria durante las pruebas.
Cómo reducir el riesgo en servicios conectados
Entre las medidas recomendadas está mantener actualizados los componentes encargados de procesar archivos y revisar los sistemas que aceptan formatos como HEIC o AVIF. Cuando su uso no sea necesario, pueden desactivarse. Otra opción es procesar los archivos recibidos desde el exterior en entornos aislados, de manera que un fallo no permita avanzar hacia otras partes del sistema.
Limitar los permisos entre plataformas también reduce la exposición. Una cuenta comprometida representa un riesgo mayor cuando permite alcanzar correo electrónico, herramientas corporativas o espacios donde se almacena código. Restringir esas conexiones puede disminuir las consecuencias de un ataque.
En este caso, la cadena involucró componentes desarrollados por distintas organizaciones, mientras que la vulnerabilidad en el inicio de sesión fue el elemento que los especialistas atribuyeron directamente a OpenAI. Esa segunda falla fue la que permitió ampliar el alcance desde un foro de ayuda hasta cuentas conectadas con otros servicios.
Aún quedan dos datos sin respuesta. Hacktron AI no publicó los detalles técnicos de la vulnerabilidad en el inicio de sesión y tampoco existe evidencia en las fuentes disponibles de que otra persona la hubiera aprovechado antes de su corrección. Lo documentado hasta ahora corresponde a la prueba realizada por el equipo, no a otros accesos derivados del mismo fallo.
