Un fallo en una imagen de un foro abrió la puerta a las cuentas de empleados de OpenAI
Investigadores explotaron una vulnerabilidad de libheif en Discourse para acceder a cuentas de empleados de OpenAI y a un repositorio interno.
Texto generado por inteligencia artificial, publicado sin revisión humana. Transparencia IA
Imagen ilustrativa generada con IA
Tres investigadores de Hacktron convirtieron un fallo en la pila de procesamiento de imágenes de Discourse en acceso a cuentas de empleados de OpenAI y a un repositorio interno de código. La investigación de seguridad combinó la explotación de una corrupción de memoria, desarrollo asistido por IA y una vulnerabilidad no divulgada en la arquitectura de inicio de sesión único de OpenAI.
El objetivo inicial era el foro público de ayuda de OpenAI, que funciona con Discourse. Unos archivos HEIC o HEIF especialmente diseñados llegaban a ImageMagick y a su decodificador libheif, lo que permitía a los investigadores comprometer el servidor del foro.
Ese acceso inicial no explicaba por sí solo todo el alcance del ataque. Como el foro público compartía una relación de confianza de «Iniciar sesión con OpenAI» con servicios más sensibles, los investigadores podían hacerse con el control de las cuentas de ChatGPT y Codex pertenecientes a empleados de OpenAI que eran miembros del foro. No era necesaria ninguna acción por parte de esos empleados.
Hacktron se detuvo después de crear una única solicitud de incorporación de cambios inofensiva en un repositorio interno. El equipo afirmó que no leyó el código fuente, no fusionó cambios, no desplegó nada ni accedió a información de clientes.
Un decodificador vulnerable dentro de la cadena de procesamiento de imágenes de Discourse
El foro afectado aceptaba cargas en formato HEIC y HEIF. Discourse enviaba esas imágenes a ImageMagick, que utilizaba libheif para decodificar su contenido.
El despliegue vulnerable ejecutaba libheif 1.19.7 en una imagen basada en Debian 12. El entorno del servidor utilizaba x86-64 y el asignador de memoria jemalloc, detalles importantes a la hora de convertir el fallo de memoria subyacente en un exploit funcional.
Los registros públicos no describen el efecto directo exactamente de la misma manera. El problema, identificado como CVE-2026-32882, se ha caracterizado como una lectura fuera de los límites que puede bloquear un proceso o exponer memoria adyacente. Otra descripción habla de un desbordamiento del búfer del heap capaz de acceder a datos situados fuera de la región prevista.
Discourse clasificó el riesgo resultante como ejecución remota de código y le asignó una puntuación de gravedad de 8,8 sobre 10. Por separado, los datos de vulnerabilidades verificados asignan a CVE-2026-32882 una puntuación CVSS 3.1 de 7,1, con el siguiente vector:
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H
Estas descripciones no constituyen necesariamente afirmaciones equivalentes sobre una única primitiva. Según los informes, Hacktron combinó los fallos de memoria de libheif con técnicas de explotación adicionales. La divulgación de memoria ayudó a eludir la aleatorización del diseño del espacio de direcciones, o ASLR, antes de que los investigadores lograran ejecutar código.
La corrección del proyecto original se publicó en libheif 1.22.0 en mayo de 2026, según el análisis de la investigación publicado por The Hacker News. Sin embargo, esa corrección todavía no se había incorporado al paquete de Debian incluido en la imagen del servidor del foro cuando esta se examinó en julio.
Esta brecha ilustra un problema recurrente de los despliegues: actualizar una aplicación no sustituye necesariamente una biblioteca nativa vulnerable incluida en su contenedor o en la imagen del sistema operativo.
Claude aceleró el desarrollo del exploit, pero el trabajo estuvo dirigido por personas
Al principio, Hacktron encomendó el problema de explotación a Anthropic Claude Opus 4.8. A lo largo de varias sesiones, el modelo no pudo producir un exploit funcional cuando ASLR estaba activado.
Anthropic lanzó Claude Opus 5 la noche del 24 de julio. Al plantear la misma tarea en una nueva sesión, los investigadores obtuvieron un exploit funcional contra un Mac local en unas tres horas, según Security Affairs.
El modelo no llevó a cabo de forma autónoma toda la operación. Los investigadores humanos definieron el objetivo, construyeron el entorno de pruebas, adaptaron el exploit a la arquitectura y al asignador de memoria del servidor, y supervisaron cada etapa.
También hubo un problema relacionado con los límites de seguridad. Según los informes, Opus 5 se negó a atacar un sistema que reconoció como activo. Por ello, los investigadores reprodujeron las condiciones del objetivo en una infraestructura en la nube bajo su control y la presentaron como un entorno de captura de bandera. En ese sistema, el modelo obtuvo acceso con privilegios de root y lo demostró leyendo /etc/hosts.
A continuación, el equipo adaptó el resultado a la instancia real del foro de OpenAI. Toda la cadena, desde la investigación inicial hasta el acceso a un repositorio interno, llevó menos de 72 horas.
El trabajo más amplio de Hacktron, denominado «HEIF Heist», duró aproximadamente dos meses, contó con tres investigadores y costó menos de 3000 dólares en uso de IA. Más adelante, durante el proyecto, también se utilizó GPT-5.6 Sol de OpenAI, cuando los investigadores comenzaron sin conocimientos previos del entorno objetivo.
Las afirmaciones sobre otras tecnologías afectadas requieren ciertos matices. Se examinaron rutas de procesamiento de imágenes similares en Slack, productos de Meta, GitHub Enterprise, Next.js e infraestructura relacionada con Shopify. Un problema de Next.js se confirmó mediante un aviso de Vercel, mientras que los responsables de libheif confirmaron la ejecución de código funcional para el problema asociado a Meta. No se ha establecido de forma independiente la ejecución de código en todas las aplicaciones examinadas.
El SSO compartido convirtió el acceso al servidor en un compromiso de identidades
Después de comprometer el foro, los investigadores utilizaron su relación de inicio de sesión con OpenAI para acceder a las cuentas de ChatGPT y Codex de empleados. Los trabajadores no tuvieron que hacer clic en un enlace malicioso, abrir un archivo ni aprobar una instrucción.
Por tanto, el punto clave de la escalada no se limitaba a Discourse. Hacktron lo describió como un fallo en el límite de confianza de la arquitectura de identidad de OpenAI: un servicio público con un nivel de confianza inferior podía conceder acceso con repercusiones sobre recursos de empleados de mayor valor.
Los empleados de OpenAI pueden conectar servicios como GitHub, Slack y el correo electrónico a ChatGPT o Codex. Hacktron afirmó que el mismo acceso a las cuentas podría haberse extendido teóricamente a esas integraciones, aunque el equipo decidió no utilizar deliberadamente esos permisos.
Para demostrar las consecuencias, los investigadores utilizaron la conexión de Codex de un empleado para enviar una única solicitud de incorporación de cambios a un repositorio interno de OpenAI. Afirmaron que:
- no inspeccionaron el código fuente del repositorio;
- no fusionaron la solicitud de incorporación de cambios;
- no publicaron ni desplegaron ninguna modificación;
- no accedieron a datos de clientes;
- no entraron en los recursos conectados de GitHub, Slack o correo electrónico más allá de lo necesario para la validación.
La investigación indica que comprometer otro servicio propio o de terceros que utilizara la misma relación de SSO de OpenAI podría haber producido potencialmente una escalada similar. Discourse proporcionó el punto de entrada, pero la identidad compartida determinó el alcance del impacto.
OpenAI y Discourse cerraron partes distintas de la cadena
Hacktron comunicó sus hallazgos tanto a OpenAI como a Discourse. OpenAI confirmó una corrección aproximadamente 14 horas después de recibir el informe.
El 1 de septiembre, OpenAI pagó a los investigadores una recompensa de 6500 dólares por el hallazgo relacionado con OpenAI. El pago no cubría las pruebas realizadas contra el entorno community.openai.com alojado en Discourse, que OpenAI afirmó que quedaba fuera del alcance de su programa de recompensas.
Los detalles técnicos del fallo de inicio de sesión de OpenAI no se han hecho públicos. La corrección y el pago de la recompensa confirman el hallazgo, pero la organización no ha descrito el mecanismo de toma de control de cuentas con suficiente detalle para permitir un análisis arquitectónico independiente.
Discourse preparó su parche el lunes siguiente y añadió un entorno aislado para el procesamiento de imágenes. Según los informes, los sitios de Discourse alojados recibieron la actualización. Las versiones corregidas para instalaciones autogestionadas son:
- Discourse 2026.7.0
- Discourse 2026.6.1
- Discourse 2026.5.2
- Discourse 2026.1.6
A mediados de septiembre de 2026, CVE-2026-32882 no figuraba en el catálogo de vulnerabilidades explotadas conocidas del Gobierno de Estados Unidos. En consecuencia, no existía un plazo de corrección de CISA KEV asociado a ella. Su ausencia no demuestra que no se produjera ninguna explotación no autorizada.
No se han proporcionado indicadores públicos de compromiso ni para el entorno de OpenAI ni para los sistemas de Discourse afectados.
Los equipos defensores deben abordar tanto el análisis de archivos como la exposición de identidades
Los operadores de instancias de Discourse autogestionadas deben instalar una de las versiones corregidas y reconstruir los despliegues a partir de una imagen actualizada. Actualizar únicamente la aplicación web puede dejar libheif 1.19.7 u otro paquete vulnerable en el entorno de ejecución.
La versión de seguridad más reciente identificada a principios de septiembre de 2026 era libheif 1.23.4. Los administradores deben utilizar esa versión o el paquete corregido proporcionado por el distribuidor del sistema operativo y, después, verificar qué biblioteca se carga realmente durante la ejecución.
Cuando no sea necesario admitir HEIC, HEIF o AVIF, desactivar esos formatos elimina la ruta de decodificación expuesta. Los procesadores de imágenes también deben ejecutarse en un entorno aislado, con un acceso al sistema de archivos, la red y los privilegios estrictamente restringido.
La monitorización debe abarcar bloqueos repetidos del procesamiento de imágenes, volúmenes inusuales de cargas malformadas, procesos secundarios inesperados y ejecuciones en el servidor que no puedan explicarse. Según los informes, Shopify detectó la actividad de investigación después de que miles de cargas de prueba bloquearan repetidamente sus procesadores de imágenes.
Los controles de identidad requieren una atención independiente. Los foros públicos y los sistemas de soporte no deberían compartir una relación de confianza SSO sin restricciones con servicios de empleados, administrativos o de desarrollo. Las operaciones sensibles deberían exigir una autenticación reciente, en lugar de aceptar una sesión heredada a través de una aplicación con un nivel de confianza inferior.
Las organizaciones también deberían elaborar un inventario de los permisos de los servicios conectados en ChatGPT, Codex, GitHub, Slack y los sistemas de correo electrónico. Deben revocarse las integraciones innecesarias, mientras que las conexiones restantes deberían recibir únicamente los privilegios mínimos necesarios.
Aplicar parches al decodificador cierra la ruta inicial. Restringir la confianza del SSO limita lo que un atacante puede alcanzar si se compromete otro servicio expuesto públicamente.
Fuentes
Este artículo es una reelaboración original basada en las siguientes fuentes.
