Falla libheif OpenAI: una imagen HEIC llegó al repo

En pocas palabras: Un heap buffer overflow en libheif 1.19.7, encadenado con una falla del SSO de OpenAI, permitió a Hacktron abrir el PR #1186742 en el monorepo openai/openai el 25 de julio de 2026. Todo llevó menos de 72 horas; OpenAI corrigió en unas 14 horas y pagó USD 6.500.

La falla libheif OpenAI es una cadena de dos vulnerabilidades con la que el equipo de Hacktron, el 25 de julio de 2026, tomó cuentas de ChatGPT y Codex de empleados de OpenAI y abrió el pull request #1186742 en el monorepo interno, en menos de 72 horas.

libheif es una biblioteca de código abierto que decodifica imágenes HEIF/HEIC (el formato que usan los iPhone por defecto) y AVIF. En este caso, la versión 1.19.7 que traía Debian 12 no tenía los fixes de seguridad y sufría un heap buffer overflow, que da lectura y escritura fuera de límites al decodificar un HEIC. Con eso alcanzó para ejecutar código en el foro community.openai.com.

¿Qué es libheif y por qué una imagen HEIC puede ejecutar código?

Una imagen puede ejecutar código cuando la biblioteca que la lee tiene un error de memoria. Si el archivo viene armado a propósito, el decodificador escribe más allá del bloque (chunk) que reservó en el heap y pisa datos ajenos. Con eso, quien sube la imagen puede terminar controlando el flujo del programa.

El título del post de dev.to, “One write past the chunk”, evoca esa mecánica (es lectura nuestra del título, la fuente no lo define así). Cualquier servicio que convierta HEIC del lado del servidor pasa por ese paso, y ahí vive el riesgo. Para más detalles técnicos, mirá qué cambia para los usuarios Plus.

¿Cómo pasó una imagen HEIC del foro de OpenAI al repositorio?

Con dos fallas encadenadas: un heap buffer overflow en libheif que dio ejecución de código en el foro, y una mala configuración del SSO de OpenAI que convirtió esa ejecución en acceso a cuentas de ChatGPT y Codex. Según el reporte de Hacktron, todo ocurrió en menos de 72 horas.

• Entrada por el foro. Discourse valida imágenes con FastImage, que no soporta HEIF. Por eso los .heic/.heif van al comando magick de ImageMagick, que usa libheif. La imagen de Docker del foro estaba basada en Debian 12 con libheif 1.19.7.
• Ejecución de código. El overflow dio lectura y escritura fuera de límites. Hacktron confirmó RCE local a las 6:00 UTC del 25 de julio y RCE en community.openai.com hacia las 10:00 UTC.
• Salto por SSO. El foro ofrece “Sign in with OpenAI” vía auth.openai.com. Con la falla de SSO, el equipo pudo tomar sin interacción las cuentas de ChatGPT y Codex de miembros activos del foro.
• Prueba de acceso. Entre las 13:30 y las 15:30 UTC usaron la cuenta de un empleado cuyo Codex estaba conectado a la organización de GitHub de OpenAI, le pidieron abrir el PR #1186742 en openai/openai y frenaron ahí.

Los investigadores dicen que no accedieron a código interno. También señalan que el alcance teórico incluía GitHub, Slack y correo, porque la gente conecta esos servicios a Codex y ChatGPT.

Mi lectura: el exploit llama la atención, pero lo que más pesa es que un foro de ayuda y las cuentas de producción compartieran el mismo camino de identidad.

¿Qué papel tuvo Claude Opus 5 en el exploit?

Según Hacktron, Claude Opus 5 hizo el trabajo de corrupción de memoria. Con ASLR activado produjo un exploit funcional para ARM64 en unas 3 horas y lo portó a x86-64 con jemalloc, algo que Opus 4.8 no había conseguido de forma fiable en varias sesiones.

La secuencia, según el mismo reporte: el 24 de julio, Opus 4.8 encontró los fixes de seguridad sin backportear y armó un exploit con ASLR desactivado. Esa noche Anthropic lanzó Opus 5, y a las 6:00 del 25 de julio había RCE local por subida de imagen. Después dejaron al modelo en un loop autónomo /goal contra su propia instancia de Discourse Cloud, presentada como un “CTF” a través de rce.ee/ctf-forum, porque Opus se negaba a escribir exploits contra instancias remotas. A las 10:00 el agente ya había leído /etc/hosts, y el mismo script anduvo contra el foro de OpenAI. En nuestra guía de herramientas para desarrolladores profundizamos sobre esto.

Pensalo como un día normal de laboratorio: bajás la imagen de Docker, le pedís al modelo que revise el paquete y encuentre los fixes que faltan, armás el exploit, lo probás en tu Mac, lo portás a x86-64, lo dejás en un loop autónomo y cuando volvés a mirar el agente ya tiene shell. (Que el modelo rechace atacar un host remoto pero acepte un “CTF” armado a medida dice bastante sobre cuánto frenan esos límites.)

Ojo con el alcance de la afirmación: son declaraciones de los investigadores, sin verificación independiente. Y el modelo no hizo toda la cadena. La falla de SSO no vino de ahí, y el propio Hacktron aclara que no fue hacking completamente autónomo y que la guía humana siguió siendo clave.

¿La falla libheif de OpenAI fue de la IA o de configuración y parches?

Fue de parches y configuración; la IA bajó el costo de explotarla. El bug ya estaba corregido upstream en 2025, pero el commit no figuraba como fix de seguridad y no recibió CVE. Debian 12 (1.19.7) y Debian 13 (1.19.8) siguieron vulnerables hasta que Debian publicó su update para Debian 13 el 8 de agosto de 2026.

Esa es también la tesis del análisis de jamilxt en dev.to: el titular “una IA hackeó a OpenAI” vende, pero los defectos eran ordinarios y el modelo cambió el costo del ataque, no su categoría.

La línea de tiempo del reporte, según Hacktron:

• OpenAI: reporte por Bugcrowd el 25 de julio y fix confirmado unas 14 horas después. El 1 de septiembre pagó USD 6.500.
• Discourse: reporte por HackerOne el sábado, respuesta el domingo, fix el lunes, sandboxing de ImageMagick como defensa adicional y advisory GHSA-vhm9-85gw-x335 el 28 de julio.
• Alcance del premio: OpenAI aclaró que probar contra el foro alojado en Discourse estaba fuera del programa y que la recompensa reconoce “el hallazgo del lado de OpenAI, no las acciones contra Discourse”.

Hacktron también insiste en que la escalada no es específica de Discourse: es un problema del SSO de OpenAI, y cualquier servicio propio o de terceros que lo use daría el mismo acceso si lo comprometen. Ya lo cubrimos antes en el agente de Copilot para Jira.

¿Cuánto cuesta ahora explotar un bug de memoria conocido?

Menos de USD 3.000 en tokens para toda la campaña HEIF Heist, según Hacktron: tres investigadores, dos meses, y uno o dos días para adaptar el exploit a cada objetivo, sin conocer de antemano la versión de libheif, la de libc ni el entorno.

La campaña rastreó libheif en Slack, Meta, GitHub Enterprise, Ruby on Rails y frameworks de Node.js como Next.js, Astro y Gatsby. Las fuentes no traen confirmaciones de esas empresas, así que tomalo como lo que cuenta el equipo. Lo mismo vale para el salto que reportan de Opus 5 a GPT-5.6 Sol en objetivos desconocidos: no hay verificación independiente.

¿Alguien lo vio venir? Según Hacktron, solo Shopify, aun después de miles de imágenes enviadas y de crashes repetidos de los procesadores de imagen.

“Las suposiciones de seguridad tienen que ponerse a la altura de las capacidades de los atacantes”, escribieron Harsh Jaiswal, Mohan Pedhapati y Rahul Maini, según citó The Register (traducción nuestra). Para vos, la consecuencia práctica es incómoda: “es público, pero nadie se va a molestar en explotarlo” dejó de ser un plan.

Qué está confirmado y qué no

Confirmado

• El PR #1186742 en openai/openai, el 25 de julio de 2026, y el pago de USD 6.500, según Hacktron y OpenAI.
• El advisory GHSA-vhm9-85gw-x335 de Discourse y su sandboxing de ImageMagick.
• El update de Debian 13 del 8 de agosto de 2026.

Sin confirmar

• La performance de Opus 4.8, Opus 5 y GPT-5.6 Sol: solo está el relato de Hacktron.
• El impacto en Slack, Meta y el resto de la campaña HEIF Heist.
• El CVE-2026-32882 con severidad 8.8: aparece en el análisis de dev.to y no lo cotejamos contra el advisory.
• Cualquier comentario de OpenAI o Anthropic: según The Register, ninguna respondió.

¿Cómo actualizo Discourse y protejo mi servidor frente a libheif?

Si autoalojás Discourse, entrá a /var/discourse y corré git pull y después ./launcher rebuild app. Actualizar solo desde la interfaz web puede no reemplazar la imagen base, que es donde está el libheif vulnerable. Los clientes con hosting de Discourse ya están parcheados, según Hacktron. Más contexto en qué es real sobre GPT-5.

Para el resto de las apps, lo que recomienda el resumen de dev.to a partir del reporte:

• Asumí exposición si aceptás .heic, .heif o .avif de usuarios. Las familias 1.19.x a 1.23.x entran en el alcance.
• Actualizá libheif y libde265. La versión upstream citada es la v1.23.4 al 14 de septiembre de 2026.
• Mirá los advisories de tu distro, no el número de versión. Los backports llevan números viejos.
• Desactivá HEIF/AVIF si no los necesitás. Si los necesitás, aislá el decodificador en un sandbox efímero y restringí formatos y recursos con la security policy de ImageMagick.
• Vigilá los crashes repetidos del decodificador. Fue la señal que casi nadie miró.

Si tenés tu Discourse o tu app en un VPS (por ejemplo en donweb.com), en un servidor autogestionado los paquetes del sistema los actualizás vos, así que verificá el parche de tu distro en lugar de suponer que ya está.

Un criterio de verificación, propuesta nuestra y no de Hacktron: dentro del contenedor o el servidor, corré estos comandos estándar de Debian e ImageMagick y validalos en tu entorno.

dpkg -l | grep -i -E "libheif|libde265"
apt changelog libheif1
magick -list format | grep -i -E "heic|heif|avif"

El primero te dice qué versión corre, el segundo si el changelog de tu distro menciona fixes de seguridad, y el tercero si ImageMagick todavía decodifica esos formatos. Si no los necesitás, una política como esta (ejemplo a adaptar) los corta:

<policy domain="coder" rights="none" pattern="{HEIC,HEIF,AVIF}" />

Errores comunes

• Actualizar solo desde el panel web de Discourse. Puede no tocar la imagen base. Corregilo con git pull y ./launcher rebuild app.
• Fiarse del número de versión. Debian 13 traía 1.19.8 y seguía vulnerable. Corregilo leyendo el advisory o el changelog de tu distro.
• Pensar que solo importa HEIC. Hacktron incluye .heif y .avif. Corregilo revisando todos los formatos que decodifica tu pipeline.
• Esperar un CVE para actuar. El fix upstream no tuvo etiqueta de seguridad ni CVE. Corregilo siguiendo changelogs de las dependencias nativas.
• Ignorar los crashes del decodificador. Eran la huella visible del ataque. Corregilo con alertas por caídas repetidas de magick o del proceso de imágenes.

Preguntas Frecuentes

¿Cómo accedió Hacktron al repositorio interno de OpenAI?

Encadenó la ejecución de código en el foro community.openai.com, vía libheif, con la falla del SSO de OpenAI. Así tomó la cuenta de un empleado cuyo Codex estaba conectado a GitHub, abrió el PR #1186742 en openai/openai y dejó de probar. Dice que no leyó código interno.

¿Una IA hackeó a OpenAI o fue una mala configuración de SSO?

Fueron una falla de parcheo y una mala configuración del SSO, con IA acelerando el exploit. Según Hacktron, Claude Opus 5 resolvió la corrupción de memoria, pero personas eligieron el objetivo, hallaron la falla de SSO y reportaron. El propio equipo aclara que no fue hacking completamente autónomo.

¿Mi aplicación que procesa imágenes HEIC o AVIF es vulnerable?

Probablemente, si acepta .heic, .heif o .avif de usuarios y usa libheif de las familias 1.19.x a 1.23.x sin parche de seguridad. Hacktron dice que es “muy probable” que esté afectada. Confirmalo con el advisory de tu distro, porque los backports ocultan el estado real detrás del número de versión.

¿Cómo actualizo Discourse para corregir la falla de libheif?

Desde /var/discourse corré git pull y después ./launcher rebuild app. Una actualización solo por interfaz web puede no reemplazar la imagen base con el libheif vulnerable. Discourse publicó el advisory GHSA-vhm9-85gw-x335 con la guía de parche y reconstrucción.

Conclusión

Lo que cambió no es el tipo de bug sino su precio. Un fix sin etiqueta de seguridad, un backport que no llegó y un SSO demasiado confiado alcanzaron para que un foro de ayuda terminara en un PR dentro del monorepo de OpenAI, y un modelo de IA comprimió la parte difícil a horas, según los investigadores.

Qué hacer hoy: si tenés Discourse propio, reconstruí la imagen; si tu producto decodifica HEIF/AVIF, actualizá libheif y libde265, revisá los advisories de tu distro, aislá el decodificador y poné alertas por crashes repetidos. Y mirá si tus cuentas de comunidad comparten identidad con las de producción. Esa pregunta incomoda más que el exploit.

Fuentes

• Hacktron – Hacking OpenAI: reporte original con línea de tiempo y detalles técnicos
• The Register – Researchers used Claude to hack OpenAI employees’ ChatGPT accounts
• dev.to (randomchaos) – One write past the chunk, read-write on the repo
• dev.to (jamilxt) – AI Didn’t Hack OpenAI: análisis del backport de Debian y el SSO