Investigadores utilizaron Claude para hackear los sistemas internos de OpenAI en una cadena de recompensas por errores

El 25 de julio de 2026, un equipo de tres personas de la empresa de seguridad Hacktron AI utilizó Claude Opus 5 de Anthropic para encadenar dos fallos y tomar el control de cuentas de ChatGPT y Codex pertenecientes a empleados de OpenAI, y luego usó una de esas cuentas para abrir una pull request dentro del repositorio de código fuente interno de OpenAI. El punto de entrada no fue una página de inicio de sesión ni una clave de API: fue una carga de imagen en el foro de ayuda público de OpenAI, community.openai.com, que funciona con el software de foro de código abierto Discourse. El segundo fallo estaba en el propio inicio de sesión compartido de OpenAI, no en el foro. No se leyó ningún código fuente, no se fusionó nada, no se tocaron datos de clientes y el archivo no registra ningún daño en el mundo real: se trató de una investigación de seguridad notificada al proveedor, no de un ataque contra él. El registro está fechado el 18 de septiembre de 2026, el día en que TechCrunch informó del hallazgo. Este incidente figura junto a las demás entradas documentadas en the Orca AI Incident Archive, donde cada registro incluye sus propias fuentes, su gravedad, su grado de confianza y su indicador de disputa.

Dos cosas hacen que el caso sea más que una vistosa historia de bug bounty. La primera es la velocidad: Hacktron afirma que todo el recorrido, desde la primera mirada al foro hasta tener acceso al repositorio interno, llevó menos de 72 horas, y que el modelo con el que empezó no podía hacer el trabajo. La segunda es una discrepancia que ocultan las cifras principales: la CVE que nombran los artículos, CVE-2026-32882, está registrada como una lectura fuera de límites que hace fallar el software o filtra memoria, no como un fallo de ejecución de código. El propio aviso de Discourse clasifica el resultado como ejecución remota de código. Ambas cosas son ciertas, y la brecha entre ellas es donde reside realmente la contribución de la IA.

Lo que Hacktron dice haber encontrado, y cuándo

Hacktron publicó su análisis, "Hacking OpenAI", en su propio sitio el 13 de septiembre de 2026. The Wall Street Journal lo informó la noche del jueves 17 de septiembre, según TechCrunch, que siguió el viernes 18 de septiembre. Los hechos descritos ocurrieron aproximadamente ocho semanas antes, y la cronología propia de Hacktron es precisa al respecto:

• 23 de julio de 2026 — el equipo rastrea la ruta de carga de HEIF de Discourse a través de ImageMagick hasta libheif y encuentra el desbordamiento de montículo.

24 de julio de 2026 — Claude Opus 4.8 produce un exploit funcional de ejecución de código con ASLR, la defensa estándar de aleatorización de direcciones, desactivado.

• 25 de julio de 2026, 06:00 UTC — usando un modelo posterior, el equipo confirma la ejecución local de código confiable mediante la carga de una imagen con ASLR activado.

• 25 de julio de 2026, 08:00–10:00 UTC — el equipo envía un informe a través del programa de recompensas por errores de OpenAI en Bugcrowd.

• 25 de julio de 2026, 10:00 UTC — el exploit funciona contra la propia instancia de Discourse Cloud del equipo y luego contra el foro de OpenAI.

• 25 de julio de 2026, 13:30–15:30 UTC — el equipo usa la cuenta de Codex de un empleado de OpenAI para abrir una pull request inofensiva en el monorepo interno de OpenAI y luego detiene las pruebas.

• 25 de julio de 2026, 22:49:45 UTC — OpenAI responde confirmando que el problema está solucionado, aproximadamente 14 horas después del envío inicial.

• 28 de julio de 2026 — Discourse publica el aviso GHSA-vhm9-85gw-x335 con indicaciones para aplicar el parche y reconstruir.

• 1 de septiembre de 2026 — OpenAI paga una recompensa de $6,500 y marca el informe como resuelto.

Las fechas anteriores son de Hacktron, no una reconstrucción. La fecha de publicación del 13 de septiembre en su propia entrada, el reportaje del Wall Street Journal del 17 de septiembre y la nota de TechCrunch del 18 de septiembre son una secuencia separada y posterior: el trabajo ocurrió en julio, el artículo salió a mediados de septiembre.

Cómo una carga de imagen se convirtió en un compromiso del servidor

La cadena comienza con una función mundana. Normalmente, Discourse revisa las imágenes subidas con una biblioteca llamada FastImage, pero FastImage no admite HEIF, el formato contenedor que los dispositivos de Apple usan para las fotos. Por lo tanto, esos archivos se pasaban a la herramienta de línea de comandos de ImageMagick para convertirlos, que a su vez los entregaba a libheif para decodificarlos. Eso colocaba un analizador directamente frente a archivos controlados por el atacante, exactamente el patrón que tiene en mente la viñeta de dependencias de xkcd, que Hacktron cita en sus referencias.

Hacktron descubrió que al paquete libheif instalado en la imagen Docker de Discourse le faltaban correcciones de seguridad. La imagen de Discourse se compiló sobre Debian 12, que instalaba libheif 1.19.7; en ese momento, Debian 13 todavía distribuía la 1.19.8. El error en sí reside en HeifPixelImage::overlay(), que compone una imagen de superposición sobre una imagen base. Según el propio aviso de libheif, cuando un hijo de superposición tiene una profundidad de bits diferente para su canal alfa que para sus canales de color, la función indexa el plano alfa usando el stride del canal de color en lugar del del plano alfa. Con una imagen de 100 por 50 a color de 10 bits y alfa de 8 bits, el aviso calcula que el código lee 3.123 bytes más allá del final de un búfer de 7.168 bytes.

Eso le da a un atacante memoria del heap filtrada, lo que resulta útil para derrotar la aleatorización de direcciones —no, por sí sola, una shell. Pasar de la filtración a la ejecución es la parte que requirió un modelo, y es la parte que el CVE no describe. La cadena cruzó entonces un límite de confianza que, según Hacktron, es la historia real: el foro de OpenAI ofrece "Iniciar sesión con OpenAI" a través de auth.openai.com, el mismo inicio de sesión único que el personal usa en otros lugares. El control del servidor del foro significó que los investigadores pudieran tomar el control de las cuentas de ChatGPT y Codex de miembros del foro que trabajaban en OpenAI, sin interacción de las víctimas. Como lo expresa Hacktron, "la vulnerabilidad para escalar no es específica de Discourse", y cualquier servicio de OpenAI, propio o de terceros, que usara ese inicio de sesión habría concedido el mismo acceso.

Establecido, e inferido

El archivo califica este registro con confianza A, no disputado, gravedad alta y sin daños reales registrados. Esos campos se sostienen. Pero el informe es el relato de un único equipo de investigación, corroborado en lugar de reconstruido de forma independiente, y vale la pena separar lo documentado de lo afirmado.

Establecido por registros primarios. CVE-2026-32882 existe, se publicó el 19 de mayo de 2026, afecta a libheif 1.21.2 y versiones anteriores, y se corrigió en libheif 1.22.0. El registro de MITRE le otorga una puntuación de 7.1, con vector de ataque: red; complejidad: baja; privilegios requeridos: ninguno; interacción del usuario: requerida; e impactos: confidencialidad baja y disponibilidad alta: un bloqueo o una fuga de memoria. El aviso de Discourse GHSA-vhm9-85gw-x335, publicado el 28 de julio de 2026 y atribuido a hacktronai-research, se refiere al mismo CVE y califica el resultado como Alto, con 8.8, con privilegios requeridos bajos, sin interacción del usuario y alto impacto en las tres dimensiones de confidencialidad, integridad y disponibilidad. Enumera las versiones parcheadas 2026.7.0, 2026.6.1, 2026.5.2 y 2026.1.6, y afirma que la imagen de Docker más reciente incluye la versión parcheada de libheif.

Confirmado por dos medios independientes. Que los investigadores usaran Claude para encontrar y explotar la cadena, que una brecha en el foro diera lugar al acceso a las cuentas del personal, que OpenAI lo solucionara en unas 14 horas y pagara 6.500 dólares, que la prueba de acceso fuera una única pull request, y que OpenAI afirme que probar el propio foro quedaba fuera del alcance de su programa de recompensas: todo esto aparece en The Hacker News y TechCrunch, que citan directamente el informe de Hacktron.

Afirmado por Hacktron, no verificado de forma independiente.Que la ejecución de código en el foro se lograra siquiera de la manera descrita —mediante un bucle de agente autónomo y una instancia de prueba con proxy— se basa en el relato de Hacktron y no ha sido reproducida por un tercero; The Hacker News dice que se ha puesto en contacto con Hacktron para preguntar cómo se logró la ejecución de código en el foro y cuál fue el alcance del acceso a la cuenta, y no informa haber recibido respuestas. La afirmación de que la misma clase de fallo llegó a Slack, Meta, GitHub Enterprise y frameworks web está, según la propia evaluación de The Hacker News, "respaldada de forma desigual": un fallo de Next.js está confirmado en el aviso de Vercel y los mantenedores de libheif confirmaron un exploit funcional para el error relacionado con Meta, pero la afirmación más amplia de ejecución de código en muchas aplicaciones no ha sido confirmada de forma independiente. OpenAI no ha publicado ninguna descripción técnica del fallo de inicio de sesión; confirmó el hallazgo mediante la corrección y el pago, en lugar de documentar las tomas de control de cuentas.

No se ha establecido en absoluto. Cuántas cuentas de empleados eran accesibles — The Hacker News dice "varias", TechCrunch dice "múltiples" y Hacktron no da ninguna cifra. Si la falla fue utilizada alguna vez por alguien más: The Hacker News informa que no hay indicios de uso en el mundo real y señala que el CVE no estaba en la lista del gobierno de EE. UU. de vulnerabilidades que se sabe que han sido explotadas a mediados de septiembre de 2026, aunque advierte que la lista no constituye prueba en ningún sentido. Y si las organizaciones que ya habían aplicado el parche deberían seguir buscando indicios de acceso anterior — The Hacker News dice que las fuentes no se pronuncian sobre ese punto.

Lo que hicieron los modelos y lo que hicieron los humanos

El salto de capacidad es la parte que el propio Hacktron enfatiza, y está documentado con sus propias palabras en lugar de inferirse. El equipo usó primero Claude Opus 4.8, en una compilación puesta a disposición de investigadores de ciberseguridad, para inspeccionar el paquete libheif instalado y construir un exploit con ASLR deshabilitado. Con ASLR activado, se quedó atascado a lo largo de varias sesiones. Anthropic publicó Claude Opus 5 la noche del 24 de julio de 2026; en una sesión nueva, el nuevo modelo produjo un exploit ARM64 funcional para un Mac local en unas tres horas, y para las 06:00 de la mañana siguiente ya se había portado a la configuración x86-64 que usa Discourse.

Claude Opus 5 también se lanzó con salvaguardas contra la escritura de código de explotación para objetivos reales. Hacktron afirma que las eludió apuntando el modelo a su propia instancia de Discourse Cloud, proxificada a través de un host llamado rce.ee/ctf-forum para que el objetivo pareciera un ejercicio de capture-the-flag, y ejecutándolo en un bucle de objetivos autónomo. El equipo deja claro que esto no fue hacking desatendido: «la guía humana experta siguió siendo importante», escribe, mientras que la cantidad de trabajo que un equipo pequeño podía realizar aumentó drásticamente. En la campaña más amplia HEIF Heist, Hacktron afirma que utilizó GPT-5.6 Sol de OpenAI para casos en los que no sabía nada de antemano sobre el objetivo.

La economía es el argumento que Hacktron quiere que el lector se lleve. En la campaña más amplia —que rastrea la misma clase de fallo en Slack, Meta, GitHub Enterprise, Ruby on Rails y los frameworks Next.js, Astro y Gatsby—, afirma que dos meses de trabajo de tres investigadores costaron menos de $3,000 en tokens, y que adaptar cada nuevo objetivo tomó uno o dos días. También afirma que no tiene conocimiento de ninguna empresa que haya detectado la actividad excepto Shopify, a pesar de que se enviaron miles de imágenes de prueba y los procesadores de imágenes fallaron repetidamente.

¿Qué cambió después?

Discourse recibió el informe un sábado, respondió el domingo, tuvo una corrección para el lunes y publicó su aviso el 28 de julio, añadiendo el aislamiento (sandboxing) para el procesamiento de imágenes como defensa en profundidad. Su aviso advierte a quienes alojan su propia instancia que una actualización de la interfaz web por sí sola puede no reemplazar la biblioteca subyacente, y que se requiere una reconstrucción completa desde /var/discourse. Debian publicó una actualización de seguridad para libheif de Debian 13 el 8 de agosto de 2026, registrada como DSA-6417-1. En el proyecto upstream, Hacktron remite a los lectores a libheif 1.23.4 como la última versión de seguridad al 14 de septiembre de 2026, y señala que los paquetes de las distribuciones pueden incluir correcciones retroportadas bajo un número de versión anterior, por lo que hay que revisar tanto el aviso del paquete como la versión upstream.

Para OpenAI, la corrección se implementó unas 14 horas después del informe del 25 de julio, y la recompensa se pagó el 1 de septiembre. La empresa adjuntó una aclaración de alcance al pago: las pruebas contra community.openai.com, alojado en Discourse, quedaron explícitamente excluidas de su programa de recompensas por errores, y el premio reconoce el hallazgo del lado de OpenAI y no las acciones contra Discourse. Merece la pena leerlo con atención. Los $6,500 son un pago por el hallazgo de inicio de sesión, no por la cadena del foro, y el trabajo en el foro que hizo posible la cadena estaba, según la propia versión de OpenAI, fuera de alcance.

Por qué el CVE no coincide con el titular

La cobertura de este caso tiende a comprimir dos calificaciones de gravedad diferentes en una sola. El aviso de libheif y el CVE describen una lectura fuera de límites con un impacto en la confidencialidad calificado como bajo y un impacto en la disponibilidad calificado como alto: fallo o fuga de memoria. El aviso de Discourse describe lo que ocurrió cuando esa lectura se combinó con trabajo de explotación y un segundo defecto, y lo califica con 8.8 con impacto total en las tres categorías. Ninguno está equivocado; responden a preguntas diferentes. El CVE responde «¿qué tan grave es el error de la biblioteca?» y el aviso del foro responde «¿qué tan grave es el problema del foro?».

La consecuencia práctica es que un lector que revise los canales de CVE en busca de una vulnerabilidad crítica de ejecución remota de código en libheif no encontrará ninguna aquí, y podría concluir razonablemente que no se ve afectado. La propia guía de Hacktron dice lo contrario: cualquier servicio que acepte imágenes HEIC, HEIF o AVIF proporcionadas por el usuario y las decodifique mediante una libheif sin parchear debe considerarse expuesto, y el número de versión por sí solo no es una comprobación suficiente, porque los backports se aplican bajo cadenas de versión obsoletas. Las tres mitigaciones que recomienda son: actualizar libheif y libde265 a través del canal de seguridad de la distribución o a una versión upstream actual; deshabilitar la decodificación de HEIF y AVIF no confiables allí donde no sea necesaria, o aislar el procesamiento de imágenes en un entorno aislado efímero; y —la que se generaliza más allá de las bibliotecas de imágenes— limitar en qué servicios confía un inicio de sesión único y exigir una nueva verificación de identidad antes de realizar acciones sensibles, en lugar de confiar en una sesión existente.

Ese último punto es el hallazgo transferible. El foro no era la vulnerabilidad; era la puerta de entrada. Que un servicio público y de menor confianza compartiera un proveedor de identidad con las herramientas internas significaba que romper la propiedad más débil del entorno otorgaba acceso a la más fuerte. Nada en el relato de Hacktron sugiere que OpenAI hubiera sido descuidada con el foro en sí —Discourse, según la propia evaluación del equipo, «en realidad no es un objetivo fácil»— y precisamente por eso se cita el caso: lo que falló fue la frontera de confianza, no el error.