El HEIF Heist de Hacktron: una biblioteca de imágenes sin parche abrió la puerta al monorepo de OpenAI

El 18 de septiembre de 2026 el equipo de seguridad Hacktron AI publicó una cadena de explotación de varias etapas que empezó con la subida de una imagen corriente y terminó dentro del código fuente privado de OpenAI. El análisis técnico, titulado Hacking OpenAI, describe cómo tres investigadores llegaron al monorepo interno de la empresa en menos de 72 horas, y cómo un arreglo que nunca se etiquetó como arreglo dejó la puerta abierta.

Lectura relacionada: Un fallo sin clics permitió a plugins maliciosos ejecutar código en cuatro grandes agentes de programación con IA · El enjambre de agentes de OpenAI inundó RubyGems con 2.000 gemas maliciosas, según los investigadores.

El trabajo se realizó el 25 de julio de 2026 y se divulgó solo después de que los proyectos afectados distribuyeran sus parches. Hacktron afirma que su camino nunca dependió de una contraseña mal escrita, un correo de phishing o un empleado colaborador. Combinó un fallo de seguridad de memoria en un decodificador de imágenes con un fallo de configuración de identidad, y usó uno para amplificar el otro. El equipo, formado por Harsh Jaiswal, Mohan Pedhapati y Rahul Maini, amplió después la investigación del decodificador hasta una campaña que llama HEIF Heist.

Cómo funcionó la cadena

El camino documentado tiene cuatro pasos, y cada uno es común por separado.

Primer paso: una imagen llega a una biblioteca en C. community.openai.com es un foro de OpenAI que funciona con Discourse. Discourse revisa las subidas con FastImage, que no admite HEIC ni HEIF, los formatos que produce un iPhone de forma predeterminada. Los archivos en esos formatos pasan al comando magick de ImageMagick, que los entrega a libheif, un decodificador en C/C++. Según el relato de los investigadores, subir un archivo HEIC manipulado bastaba para enviar bytes controlados por el atacante directamente a un analizador nativo.

Segundo paso: el analizador se rompe. libheif contenía un desbordamiento de búfer de heap, catalogado como CVE-2026-32882 con una puntuación CVSS de 8,8. Al activarlo durante la decodificación HEIC se obtenían primitivas de lectura y escritura fuera de los límites, y el equipo las convirtió en ejecución remota de código en el contenedor del foro. El detalle que más importa está en la historia de ese código: la fuente original lo había cambiado casi un año antes en un commit rutinario de limpieza que no llevaba aviso de seguridad ni CVE. Debian, por tanto, nunca aplicó el cambio. Debian 12 y Debian 13 distribuían una versión vulnerable de libheif, y la imagen Docker de Discourse, basada en Debian 12, la heredó. Debian publicó DSA-6417-1 para Debian 13 el 8 de agosto de 2026.

Tercer paso: el foro da acceso a las cuentas de OpenAI. Con ejecución remota de código administrativa en el foro, el equipo abusó de una configuración defectuosa del inicio de sesión único de OpenAI en auth.openai.com. El foro ofrecía «Sign in with OpenAI», así que una sesión en community.openai.com tenía peso en todos los productos de consumo de OpenAI. Hacktron podía secuestrar las sesiones de ChatGPT y Codex de empleados de OpenAI que hubieran iniciado sesión, sin ninguna acción de la víctima. Los investigadores insisten en que este paso fue un problema de identidad de OpenAI y no una vulnerabilidad de Discourse, y en que cualquier servicio propio o de terceros que usara el mismo SSO habría abierto la misma puerta.

Cuarto paso: prueba, no robo. Con el Codex de un empleado, conectado a la organización de OpenAI en GitHub, el equipo le pidió abrir una pull request inofensiva, la PR #1186742, en el monorepo interno openai/openai, y después se detuvo. Hacktron afirma que no leyó ni exfiltró código interno. Un pull request abierto desde dentro del perímetro corporativo demuestra el acceso de escritura con más limpieza que una captura de pantalla, y es la clase de prueba sobre la que puede actuar un programa de recompensas.

Un foro es un objetivo de poco valor hasta que se conecta al sistema de identidad que protege todo lo demás. Ese cableado es lo que Hacktron cabalgó hasta las cuentas de OpenAI.

Por qué el arreglo sin etiqueta es la verdadera historia

El titular es que unos investigadores llegaron al código interno de una empresa de IA. La lección más transferible es lo que ocurre cuando el trabajo de seguridad se distribuye sin etiqueta de seguridad.

Las bases de datos de vulnerabilidades se guían por identificadores. Las distribuciones deciden qué aplicar en versiones anteriores a partir de avisos, CVE y notas de versión. Cuando un arreglo de seguridad de memoria llega como mantenimiento rutinario bajo un título neutro, ninguna de esas señales se activa. El cambio de libheif se consideró limpieza, así que el ecosistema no tenía motivo para mirar, y la versión vulnerable conservó su lugar en las imágenes de contenedor mucho después de que el código se hubiera corregido en la fuente. El relato de The State of AI plantea la exposición en términos parecidos: el fallo estaba arreglado, pero nadie sabía que había que decirlo.

Esa brecha no es rara, y gana importancia a medida que las pilas de software se vuelven más profundas. Este fallo no vivía en un foro, un framework ni una aplicación. Estaba varias capas más abajo, dentro de un decodificador que llega a producción mediante envoltorios como ImageMagick, libvips y sharp, y mediante imágenes base precompiladas que pocos equipos actualizan a mano. Una empresa puede seguir con cuidado sus dependencias directas y aun así quedar expuesta por una dependencia transitiva que nunca listó.

Los números de versión tampoco son una comprobación fiable por sí solos. Una distribución puede aplicar un arreglo sin cambiar la versión visible de la fuente original, y un contenedor puede fijar un paquete antiguo del sistema incluso después de reconstruir la aplicación que va encima. El análisis de lilting.ch lo dice con claridad: lo que importa es qué versión se ejecuta de verdad, lo que obliga a leer el aviso de seguridad de la distribución junto con el registro de cambios del paquete en lugar de confiar en una cadena de un archivo de bloqueo.

Discourse actuó con rapidez en cuanto tuvo el informe. Añadió un aislamiento alrededor de ImageMagick, distribuyó un arreglo el lunes 27 de julio y publicó el aviso GHSA-vhm9-85gw-x335 el 28 de julio de 2026. El aislamiento es la parte que merece copiarse. Los fallos de seguridad de memoria en los analizadores de imágenes seguirán apareciendo, así que la defensa duradera consiste en dar por hecho que un decodificador será comprometido y colocarlo donde un compromiso no llegue al anfitrión, en lugar de apostar a que el próximo parche llegue a tiempo.

La capa de identidad convirtió un fallo de foro en un problema de empresa

Un foro comunitario es un objetivo de poco valor en la mayoría de los modelos de amenaza. Guarda conversaciones, no secretos. Esa suposición se rompe en el momento en que el foro usa el proveedor de identidad de la propia empresa para el inicio de sesión.

Como community.openai.com permitía «Sign in with OpenAI», un compromiso del servidor del foro se convirtió en un punto de apoyo en el flujo de identidad. Hacktron pudo secuestrar las sesiones de ChatGPT y Codex de empleados y otros miembros activos del foro sin engañar a nadie. El alcance potencial iba más allá de ChatGPT: las cuentas suelen estar conectadas a otros servicios, y los investigadores mencionan GitHub, Slack y el correo entre las integraciones que podría tocar una sesión secuestrada.

La lección se extiende mucho más allá de OpenAI. Cualquier organización que permita que propiedades de terceros o comunitarias se autentiquen mediante su sistema de identidad corporativa ha creado un camino desde el servicio menos fiable hasta las cuentas más fiables. Delimitar el alcance importa aquí tanto como parchear. Un token de inicio de sesión emitido para un foro de debate no debería tener la autoridad de una credencial de API para los productos estrella de la empresa, y el arreglo que OpenAI desplegó fue en esa configuración de identidad, no en Discourse.

El informe de Cyber Kendra sobre la divulgación enmarca la misma división: el foro fue el punto de entrada, pero la escalada que importó fue la confianza concedida a una sesión. Revisar qué aplicaciones pueden emitir tokens para qué audiencias, y acortar la vida de esos tokens, hace más contra esta clase de ataque que cualquier parche de servidor aislado.

Los exploits escritos por IA cambiaron el ritmo

El desarrollo de exploits era antes un cuello de botella que favorecía a los defensores. Convertir una primitiva de lectura o escritura fuera de límites en una carga útil fiable implica vencer la aleatorización del espacio de direcciones y acertar con el asignador de memoria del objetivo, un trabajo que a un especialista le costaba días o semanas.

El relato de Hacktron muestra cómo se adelgaza ese cuello de botella. El equipo afirma que Claude Opus 4.8 analizó la imagen de Discourse y descubrió que los arreglos de seguridad no se habían aplicado en su paquete libheif, pero no logró producir un exploit funcional con ASLR activado en varias sesiones. Horas después de que Anthropic distribuyera Claude Opus 5, el mismo encargo produjo un exploit funcional para ARM64 en unas tres horas. El equipo pidió entonces al modelo portarlo a la disposición x86-64 y jemalloc que usa Discourse, y a primera hora del 25 de julio ya había confirmado la ejecución de código mediante una subida de imagen.

Los investigadores ejecutaron el modelo en un bucle autónomo contra una instancia que controlaban y que simulaba ser un objetivo de captura de bandera, porque el modelo se había negado a escribir un exploit dirigido a un sistema remoto en vivo. El mismo script generado funcionó después contra el foro de OpenAI. Lo que hay que retener no es qué modelo ganó, sino que el límite pasó de «ningún exploit funcional» a «exploit funcional en tres horas» dentro de un solo ciclo de lanzamiento, y que las partes difíciles y repetitivas de la explotación son justo las que un agente puede trabajar sin descanso.

Qué hay que observar

Tres cosas decidirán cuánto importa esta historia. La primera es si el resto de los hallazgos de HEIF Heist se convierten en avisos. Hacktron afirma que la misma clase de decodificador llegó a Slack, a los productos centrales de Meta, a Next.js y a GitHub Enterprise Server, donde un fallo relacionado está catalogado como CVE-2026-19118 y se corrigió en la versión 3.21.5 el 1 de septiembre de 2026. Vercel desactivó la optimización AVIF en su servicio gestionado mientras se propagaba el arreglo en la fuente original. Si otros proveedores confirman caminos similares, la lección pasa de un solo foro a toda la cadena de suministro del procesamiento de imágenes.

La segunda es la rapidez con la que reaccionan de verdad los consumidores posteriores. Se recomienda a los usuarios de libheif actualizar a 1.23.2 o posterior, y la última versión de seguridad era 1.23.4 a mediados de septiembre de 2026. Donde no se necesite decodificar HEIF o AVIF, conviene desactivarlo en la capa de aplicación. Donde sí se necesite, el procesamiento de imágenes debe ir en un entorno aislado, endurecido y efímero, como hace Discourse ahora.

La tercera es el alcance de la identidad. El hallazgo de OpenAI se corrigió unas 14 horas después del informe, y la empresa pagó una recompensa de 6.500 dólares a la vez que señalaba que las pruebas contra el foro quedaban fuera del alcance de su programa. Esa división refleja con justicia dónde estaba la culpa, pero también significa que la lección más reutilizable, que un foro comunitario no debería ser una llave maestra, todavía se está asimilando en el sector.

Portada: Wikimedia Commons «Person holding the OpenAI icon.jpg» de FoxTPNL, CC BY 4.0 (recortada a 16:9).