La frase más llamativa es que Claude hackeó OpenAI. También es la forma más rápida de contar mal lo que ocurrió.
Claude no decidió atacar por su cuenta ni hubo una guerra autónoma entre modelos. Tres investigadores de Hacktron AI usaron modelos de Anthropic como herramientas para desarrollar un exploit, encadenaron dos fallos diferentes y consiguieron acceso a cuentas internas de OpenAI. Cuando demostraron que podían alcanzar un repositorio privado, detuvieron la prueba y notificaron el problema mediante el programa de recompensas.
El incidente es real y está documentado con detalle en la investigación técnica publicada por Hacktron. También es más interesante que el titular, porque muestra cómo una vulnerabilidad en un foro público puede cruzar límites de confianza hasta terminar dentro de la infraestructura corporativa.
El ataque no empezó en ChatGPT
El punto de entrada fue community.openai.com, el foro de ayuda que OpenAI operaba sobre Discourse. El 23 de julio de 2026, el equipo comenzó a revisar cómo la plataforma procesaba imágenes subidas por sus usuarios.
La mayoría de los formatos pasaban por un flujo habitual, pero los archivos HEIC y HEIF seguían otro camino. Como el componente inicial no podía reconocerlos, Discourse los enviaba a ImageMagick para convertirlos. ImageMagick, a su vez, utilizaba libheif para decodificarlos.
Esto colocaba una biblioteca nativa escrita en C y C++ frente a archivos controlados por cualquier usuario. La ruta completa parecía una función inocente —subir una imagen al foro—, pero terminaba exponiendo un parser complejo a datos que podían haberse fabricado específicamente para romperlo.
Hacktron encontró que la imagen de Docker de Discourse incluía una versión vulnerable de libheif. Algunos cambios de seguridad realizados en el proyecto original no habían llegado a los paquetes utilizados por Debian. El resultado era un desbordamiento de búfer en el heap que podía convertirse en lectura y escritura fuera de límites y, finalmente, en ejecución remota de código.
La existencia y corrección del problema también quedaron registradas en el aviso de seguridad GHSA-vhm9-85gw-x335 de Discourse. Discourse añadió aislamiento al procesamiento de imágenes como defensa adicional.
Qué hizo Claude realmente
Los investigadores no entregaron el objetivo a una IA y se fueron a dormir esperando que todo apareciera resuelto. El trabajo combinó dirección humana, infraestructura de prueba, varias sesiones de modelos y correcciones manuales.
Primero utilizaron Claude Opus 4.8 para inspeccionar el paquete de libheif instalado y localizar cambios de seguridad que no habían sido incorporados. Ese modelo ayudó a producir un exploit funcional cuando ASLR —la aleatorización de direcciones de memoria— estaba desactivado, pero tuvo dificultades para hacerlo confiable en la configuración real.
La noche del 24 de julio Anthropic lanzó Claude Opus 5. Hacktron repitió el problema con el nuevo modelo. Según el relato de los investigadores, produjo un exploit para ARM64 en unas tres horas y después lo adaptó al entorno x86-64 con jemalloc utilizado por Discourse. La existencia del modelo y su lanzamiento pueden contrastarse en el anuncio oficial de Claude Opus 5.
Después ejecutaron al agente contra una instancia propia de Discourse Cloud, presentada como un reto CTF. El modelo se había negado a escribir el exploit para un objetivo remoto real, así que la prueba se hizo primero en un entorno controlado. Cuando la cadena funcionó allí, el equipo la reprodujo en el foro de OpenAI.
Del archivo HEIF a una cuenta de empleado
Conseguir ejecución de código en un foro ya era una vulnerabilidad crítica, pero todavía no explicaba cómo llegaron a ChatGPT, Codex y GitHub. Para eso hizo falta un segundo fallo.
El foro permitía iniciar sesión mediante la identidad de OpenAI. De acuerdo con Hacktron, la arquitectura SSO no aislaba correctamente la confianza concedida al foro de la sesión utilizada en otros productos. Al comprometer el entorno de Discourse, pudieron apoderarse de cuentas de miembros activos del foro y usar esas sesiones en ChatGPT y Codex.
Ese detalle cambia la dimensión del incidente. Un servicio comunitario debería representar una zona menos confiable que los sistemas internos. Sin embargo, la sesión obtenida a través de esa superficie pública abría una ruta hacia productos que podían tener conectores con GitHub, Slack y correo electrónico.
La cadena completa fue esta:
| Etapa | Qué ocurrió |
|---|---|
| 1. Carga | Un archivo HEIF controlado llegó al procesador de imágenes del foro |
| 2. Decodificación | ImageMagick delegó el formato a una versión vulnerable de libheif |
| 3. Explotación | El desbordamiento de memoria terminó en ejecución remota de código |
| 4. Identidad | El fallo de SSO permitió secuestrar sesiones de usuarios activos |
| 5. Expansión | Una cuenta de empleado abrió acceso a ChatGPT y Codex |
| 6. Prueba | Codex creó una pull request inocua en el monorepo interno de OpenAI |
No fue una sola vulnerabilidad milagrosa. Fue una cadena: una dependencia sin parche, un procesamiento de archivos expuesto, un límite de identidad demasiado amplio y una integración con acceso a recursos internos.
La pull request que demostró el impacto
Los investigadores accedieron a la cuenta de un empleado cuyo Codex estaba conectado a la organización de GitHub de OpenAI. En lugar de abrir o descargar el código privado, enviaron una instrucción a Codex para crear una pull request inocua en el monorepo openai/openai.
La prueba apareció como la PR #1186742. Hacktron afirma que no inspeccionó el código fuente y que detuvo todas las pruebas después de demostrar el acceso. El enlace y los detalles sensibles fueron ocultados a petición de OpenAI.
Ese enfoque importa. En una divulgación responsable no hace falta extraer información para demostrar que podría extraerse. Una modificación controlada y reversible puede acreditar el alcance sin convertir una investigación defensiva en un incidente destructivo.
El reporte inicial se presentó en Bugcrowd el 25 de julio. Según la cronología publicada, OpenAI confirmó la corrección de su lado unas 14 horas después del envío. Discourse recibió un reporte separado mediante HackerOne, preparó una solución el 27 de julio y publicó su aviso el día siguiente.
El 1 de septiembre OpenAI marcó el caso como resuelto y pagó una recompensa de 6,500 dólares. La propia nota reproducida por Hacktron aclara que el foro administrado por Discourse estaba fuera del alcance formal del programa: la recompensa correspondió al fallo de identidad del lado de OpenAI.
Menos de 72 horas no significa empezar desde cero
Hacktron resume que transcurrieron menos de 72 horas desde el descubrimiento inicial hasta el acceso al repositorio. Es una cifra relevante, pero necesita contexto.
El equipo estaba formado por investigadores especializados. Ya conocía técnicas de explotación, sabía construir entornos de prueba y podía evaluar cuándo una respuesta del modelo era útil o peligrosa. Claude redujo el costo de explorar variantes y adaptar el exploit; no convirtió una persona sin experiencia en investigadora de memoria de la noche a la mañana.
La campaña más amplia, llamada HEIF Heist, duró dos meses, costó menos de 3,000 dólares en tokens y estudió la presencia de libheif en más plataformas. Hacktron asegura que adaptar la explotación a un nuevo objetivo solía tomar uno o dos días.
La conclusión preocupante no es que cualquiera pueda escribir una frase y comprometer OpenAI. Es que un equipo pequeño y capacitado ahora puede probar muchas más hipótesis, portar código entre arquitecturas y convertir fallos públicos en exploits utilizables mucho más rápido.
El verdadero fallo estaba en los límites de confianza
El error de memoria fue la puerta, pero la arquitectura determinó hasta dónde conducía.
Si el foro hubiera tenido una identidad limitada exclusivamente al foro, el compromiso habría sido grave pero contenido. Si el procesador de imágenes hubiera estado aislado dentro de un sandbox efímero sin credenciales ni acceso lateral, la ejecución de código habría tenido menos valor. Si Codex hubiera requerido una autorización adicional antes de operar sobre un repositorio interno, la última etapa habría encontrado otra barrera.
Esto es defensa en profundidad: asumir que alguna capa terminará fallando y evitar que ese fallo herede automáticamente la confianza de las demás.
Para un proyecto pequeño, las lecciones son bastante concretas:
- Procesa archivos de usuarios en un entorno aislado, con pocos permisos, límites de memoria y tiempo de ejecución.
- Mantén actualizadas también las bibliotecas nativas que llegan dentro de imágenes Docker; actualizar únicamente la aplicación no siempre reemplaza el sistema base.
- Separa audiencias, permisos y cookies entre productos, incluso cuando todos pertenecen a la misma empresa.
- No permitas que una sesión obtenida en un servicio comunitario sea suficiente para entrar a herramientas administrativas.
- Revisa qué repositorios, correos o canales puede utilizar un agente conectado a la cuenta de un empleado.
- Exige confirmación humana para acciones sensibles y conserva registros que permitan reconstruirlas.
La IA también cambia la economía de defender
Durante años, muchas vulnerabilidades permanecieron poco explotadas porque convertir un fallo en un ataque confiable exigía tiempo y conocimiento escaso. Eso nunca fue una medida de seguridad real, pero sí funcionaba como una barrera económica.
El caso de OpenAI muestra que esa barrera está bajando. Un modelo puede revisar diferencias entre versiones, proponer primitivas de explotación, portar código y mantener varios intentos en paralelo. El mismo aumento de capacidad está disponible para equipos defensivos, programas de recompensas y responsables de software libre.
La respuesta no puede ser confiar en que el atacante todavía no sabe cómo hacerlo. Tiene que ser reducir superficies, parchear dependencias, aislar procesadores peligrosos y diseñar identidades cuyo alcance termine exactamente donde debe terminar.
Claude no hackeó OpenAI por voluntad propia. Tres investigadores usaron IA para recorrer más rápido una cadena que la arquitectura ya hacía posible. Y esa diferencia es precisamente lo que vuelve importante esta historia: el modelo no creó los límites de confianza rotos, pero ayudó a demostrar en días lo lejos que permitían llegar.