⏱️ Lectura: 12 min
El 25 de julio de 2026, dos vulnerabilidades encadenadas le dieron a un equipo de tres investigadores acceso a las cuentas de ChatGPT y Codex de empleados de OpenAI, y de ahí, a los repositorios internos de la compañía. Todo el proceso, desde el primer hallazgo hasta un pull request dentro del monorepo openai/openai, tomó menos de 72 horas.
📑 En este artículo
El punto de entrada no fue un modelo de IA ni un prompt malicioso: fue una vulnerabilidad clásica de libheif, la librería que decodifica imágenes HEIF/HEIC, explotada a través del foro público de soporte de OpenAI.
TL;DR
- El 25 de julio de 2026, Hacktron encadenó un RCE en libheif con un fallo de SSO de OpenAI.
- El vector fue una imagen .heic subida al foro community.openai.com, procesada por ImageMagick vía libheif.
- Con acceso admin a Discourse y la falla de SSO en auth.openai.com, tomaron cuentas ChatGPT y Codex de empleados.
- Usaron el Codex comprometido para abrir el PR #1186742 en el monorepo interno openai/openai como prueba de concepto.
- De la primera RCE al acceso a repos internos pasaron menos de 72 horas.
- OpenAI confirmó el fix unas 14 horas después del reporte, a las 22:49:45 UTC del 25 de julio.
- Discourse publicó el advisory GHSA-vhm9-85gw-x335 el 28 de julio con parche y sandboxing de imágenes.
- OpenAI pagó 6.500 dólares de bounty el 1 de septiembre, aclarando que el hallazgo sobre Discourse quedó fuera de su programa.
Qué pasó: la vulnerabilidad libheif en el foro de OpenAI
El equipo detrás del hallazgo se llama Hacktron y confirmó haber obtenido ejecución remota de código (RCE) y acceso administrativo total al Discourse que corre en community.openai.com, el foro oficial de soporte de OpenAI. Ese acceso llegó entre las 05:00 y las 06:00 UTC del 25 de julio de 2026.
Entre las 08:00 y las 10:00 UTC del mismo día, Hacktron reportó el hallazgo a través del programa de bug bounty de OpenAI en Bugcrowd. Horas más tarde, entre las 13:30 y las 15:30 UTC, demostraron el impacto real: usaron el acceso para abrir un pull request inofensivo, identificado como PR #1186742, dentro del monorepo interno openai/openai. Después de eso, detuvieron toda actividad de prueba y avisaron a contactos de OpenAI.
OpenAI confirmó que había corregido el problema a las 22:49:45 UTC, apenas 14 horas después del reporte inicial. Discourse, el software de foros de código abierto que usa OpenAI, recibió un reporte separado por HackerOne ese mismo día; respondió el 26 de julio, tuvo un parche listo el 27 y publicó el advisory GHSA-vhm9-85gw-x335 el 28 de julio, con guía de parcheo y una capa adicional de sandboxing para el procesamiento de imágenes.
El cierre formal llegó recién el 1 de septiembre de 2026: OpenAI pagó una recompensa de 6.500 dólares y marcó el caso como resuelto, aclarando en su respuesta que las pruebas contra el Discourse alojado en community.openai.com estaban explícitamente fuera del alcance de su programa de bug bounty. El premio, según la empresa, reconocía únicamente el hallazgo del lado de OpenAI, la falla de SSO, no la explotación de Discourse.
Contexto e historia
Hacktron es un equipo pequeño liderado por Harsh Jaiswal, junto a Mohan Pedhapati y Rahul Maini, dedicado a buscar vulnerabilidades en compañías de IA de frontera. Meses antes de este hallazgo ya habían detectado una falla de configuración en la infraestructura de identidad de OpenAI, la misma pieza de SSO que terminaría siendo el segundo eslabón de esta cadena.
El hallazgo de libheif en Discourse no fue un hecho aislado para el equipo: lo integraron a una investigación más amplia bautizada HEIF Heist, que lleva meses rastreando dónde más se usa esta librería de decodificación de imágenes. Según Hacktron, el rastro llega a Slack, Meta, GitHub Enterprise, aplicaciones sobre Ruby on Rails, y frameworks de Node.js como Next.js, Astro y Gatsby. La conclusión del equipo es simple: una cantidad sorprendente de software depende de una sola librería de imágenes, y cuando esa librería falla, el radio de impacto es enorme.
Detalles técnicos de la cadena de exploits
La cadena completa tiene ocho eslabones, y cada uno por separado parece menor. Juntos, permitieron tomar control de cuentas corporativas de OpenAI.
Todo arrancó con una imagen con extensión .heic subida como avatar o adjunto en community.openai.com. Discourse delega el procesamiento de imágenes en ImageMagick, que a su vez usa libheif para decodificar el formato HEIF. La versión de libheif empaquetada en la imagen Docker de Discourse tenía un heap buffer overflow conocido, pero sin corregir: Debian nunca aplicó el backport de seguridad correspondiente a esa rama, así que la corrección nunca llegó al paquete que Discourse instala por defecto.
Ese desbordamiento de heap, disparado simplemente al procesar la imagen maliciosa durante la subida, le dio a Hacktron ejecución remota de código dentro del contenedor de Discourse, y de ahí, acceso administrativo completo al foro.
El segundo eslabón fue independiente del primero: OpenAI permite iniciar sesión en el foro con Sign in with OpenAI, un flujo de SSO servido desde auth.openai.com. Hacktron ya conocía una falla en ese flujo de identidad por una investigación anterior. Con acceso administrativo a Discourse más esa falla de SSO, pudieron moverse desde el foro hacia las cuentas reales de ChatGPT y Codex de empleados de OpenAI. Y como Codex puede conectarse a GitHub, Slack y correo corporativo, el radio de exposición teórico incluía todos esos sistemas.
flowchart TD
A["Imagen .heic maliciosa"] --> B["Subida a community.openai.com"]
B --> C["Discourse invoca ImageMagick"]
C --> D["ImageMagick delega en libheif"]
D --> E["Heap buffer overflow en libheif"]
E --> F["RCE y admin en Discourse"]
F --> G["Falla de SSO en auth.openai.com"]
G --> H["Toma de cuentas ChatGPT y Codex"]
H --> I[("PR de prueba en openai/openai")]Para un desarrollador que administra su propio Discourse, el primer paso práctico es confirmar si su instalación todavía depende de una versión vulnerable de libheif. Dentro del contenedor de la aplicación se puede correr:
# dentro del contenedor de Discourse (docker exec -it app bash)
dpkg -l | grep libheif
ldconfig -p | grep libheifSi el paquete instalado es anterior al backport de seguridad de Debian para esa rama, la instalación sigue expuesta a la misma clase de heap buffer overflow que usó Hacktron.
Cómo protegerte si autoalojás Discourse
Discourse-hosted, la versión administrada que ofrece la propia empresa, ya está parcheada: no hace falta ninguna acción. El problema real es para quienes corren Discourse por su cuenta con Docker, que es la mayoría de las instalaciones self-hosted.
El advisory oficial es explícito en un punto que suele pasarse por alto: actualizar solo desde la interfaz web de administración no basta, porque esa vía no reemplaza la imagen base del contenedor donde vive la libheif vulnerable. Hace falta reconstruir la imagen completa:
cd /var/discourse
git pull
./launcher rebuild appEse comando descarga la definición actualizada del contenedor y reconstruye la aplicación desde cero, lo que sí reemplaza la libheif vulnerable. Como defensa adicional, Discourse también sumó sandboxing al pipeline de procesamiento de imágenes, para que un futuro fallo de decodificación no se traduzca directamente en RCE sobre el proceso principal.
| Instalación | Estado tras el 28 de julio | Acción recomendada |
|---|---|---|
| Discourse-hosted (SaaS oficial) | Parcheado por el proveedor | Ninguna |
Self-hosted, reconstruida con launcher rebuild | Parcheado si se corrió después del 28 de julio | Verificar versión de libheif con dpkg -l |
| Self-hosted, solo actualizada desde el panel web | Probablemente vulnerable | Ejecutar git pull y ./launcher rebuild app desde /var/discourse |
⚠️ Ojo: si administrás un Discourse propio y solo aplicaste actualizaciones desde el panel de administración web, tu instalación puede seguir corriendo la libheif vulnerable. El advisory pide explícitamente reconstruir la imagen completa con ./launcher rebuild app.
Impacto y análisis
Lo que hace grave a este caso no es solo la vulnerabilidad puntual en libheif, sino la superficie que conectaba con ella. Community.openai.com es un foro de soporte, un componente que muchas organizaciones tratarían como de bajo riesgo. Pero al estar integrado con el mismo sistema de identidad que protege ChatGPT y Codex, cualquier compromiso ahí escalaba directo a cuentas corporativas reales.
Codex, el agente de código de OpenAI, puede conectarse a GitHub, y potencialmente a Slack y correo. Eso significa que una falla en un foro de ayuda terminó, en teoría, a un paso de repositorios privados, canales internos y bandejas de entrada corporativas. Hacktron se detuvo deliberadamente antes de explorar esa superficie completa: usaron el acceso solo para demostrar impacto con un PR inofensivo, sin leer información sensible.
La respuesta de OpenAI también deja una lección editorial para cualquier programa de bug bounty: la compañía separó con cuidado qué parte del hallazgo pagaba, la falla de SSO propia, de qué parte quedaba fuera de alcance, la explotación de un servicio de terceros, Discourse, aunque estuviera alojado bajo su propio dominio. Es un recordatorio de que el scope de un bug bounty no siempre sigue al dominio: sigue al código que la empresa controla directamente.
💡 Tip: si tu producto acepta subidas de imágenes .heic, .heif o .avif de usuarios, es candidato directo para la investigación HEIF Heist de Hacktron. El equipo ofrece ayuda en [email protected].
Qué sigue
Hacktron adelantó que HEIF Heist sigue activa y que ya rastrearon libheif en Slack, Meta, GitHub Enterprise y frameworks de Node.js como Next.js, Astro y Gatsby, además de aplicaciones sobre Ruby on Rails. Es probable que en los próximos meses aparezcan más advisories relacionados con la misma librería, en productos que ni siquiera saben que la usan de forma transitiva, a través de ImageMagick, libvips u otras herramientas de procesamiento de imágenes.
Para equipos de seguridad, el caso deja una tarea concreta: auditar qué componentes de bajo perfil, como foros, wikis o sistemas de tickets, están conectados al mismo proveedor de identidad que protege los sistemas críticos, y tratarlos con el mismo rigor de parcheo.
📖 Resumen en Telegram: Ver resumen
Probalo vos: si administrás Discourse propio, corré hoy mismo dpkg -l | grep libheif dentro del contenedor para confirmar si seguís expuesto antes de reconstruir la imagen.
Preguntas frecuentes
¿Qué es libheif y por qué es tan común?
Es la librería de código abierto que decodifica imágenes en formato HEIF/HEIC, el formato que usan por defecto los iPhone desde 2017. La usan de forma directa o transitiva, a través de ImageMagick u otras herramientas, una cantidad enorme de aplicaciones que aceptan subida de imágenes, lo que explica el radio de impacto que documenta la investigación HEIF Heist de Hacktron.
¿Community.openai.com sigue vulnerable?
No. OpenAI confirmó el fix del lado de su infraestructura de SSO el 25 de julio de 2026, y Discourse publicó su parche con sandboxing adicional el 28 de julio en el advisory GHSA-vhm9-85gw-x335.
¿Mi Discourse propio está en riesgo?
Depende de cómo lo actualizaste. Si solo aplicaste cambios desde el panel de administración web sin reconstruir la imagen Docker completa con ./launcher rebuild app, es probable que sigas corriendo la libheif vulnerable.
¿Por qué OpenAI pagó solo 6.500 dólares si el impacto fue tan grande?
Porque OpenAI acotó el pago al hallazgo que consideró dentro de su propio scope: la falla de SSO en auth.openai.com. La explotación de Discourse, aunque estaba alojada en community.openai.com, la compañía la marcó como fuera del alcance de su programa de bug bounty en Bugcrowd.
¿Hacktron llegó a ver información sensible de OpenAI?
Según su propio relato, no: se detuvieron después de abrir el pull request de prueba PR #1186742 en el monorepo interno openai/openai, sin leer datos internos, y notificaron a OpenAI de inmediato.
¿Qué otros productos podrían estar afectados por libheif?
La investigación HEIF Heist de Hacktron menciona rastros de libheif en Slack, Meta, GitHub Enterprise, aplicaciones sobre Ruby on Rails y frameworks de Node.js como Next.js, Astro y Gatsby, entre otros.
Referencias
- Hacktron: Hacking OpenAI: el relato técnico original con la línea de tiempo completa del hallazgo.
- GitHub Security Advisory GHSA-vhm9-85gw-x335: advisory de Discourse sobre la vulnerabilidad de libheif en el procesamiento de imágenes.
- Programa de bug bounty de OpenAI en Bugcrowd: canal usado por Hacktron para reportar el hallazgo del lado de OpenAI.
- Discourse Meta: comunidad y documentación oficial del proyecto Discourse.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
Imagen destacada: Foto de GuerrillaBuzz en Unsplash
0 Comentarios