Un equipo de investigadores de seguridad tomó el control de cuentas de empleados de OpenAI encadenando dos fallos distintos: un error de procesamiento de imágenes en una librería usada por ImageMagick, y una debilidad en el inicio de sesión único que conecta varios servicios internos. El exploit se construyó con la ayuda de Claude Opus 5, empleado como copiloto ofensivo para acelerar el análisis y el encadenamiento de las vulnerabilidades.
Una imagen HEIF manipulada como puerta de entrada
El foro público de ayuda de OpenAI, alojado en Discourse, acepta imágenes en formato HEIF y HEIC subidas por los usuarios. Esos archivos pasan después por ImageMagick, que delega la decodificación a la librería libheif. Un fallo de corrupción de memoria en esa librería permitía que una imagen especialmente manipulada comprometiera el servidor que la analizaba, un caso clásico de contenido no confiable deserializado en el servidor.
Este tipo de flujo de procesamiento de imágenes sigue siendo un punto ciego frecuente: la conversión de formatos poco habituales suele delegarse a librerías de terceros con mucha menos revisión que el código de la aplicación principal, que es lo que un equipo de seguridad vigila con más atención.
El inicio de sesión único, el eslabón débil de la cadena
Comprometer el servidor del foro habría tenido un impacto limitado por sí solo si no hubiera abierto el acceso a la identidad compartida usada por otros servicios de OpenAI. Según los investigadores de Hacktron, el segundo fallo era menos un error del software del foro que un problema de diseño: cualquier servicio, propio o de terceros, conectado al mismo proveedor de identidad podría haber concedido el mismo nivel de acceso.
| Paso | Componente afectado | Naturaleza del fallo |
|---|---|---|
| 1 | Discourse → ImageMagick → libheif | Corrupción de memoria al decodificar una imagen HEIF manipulada |
| 2 | Inicio de sesión único de OpenAI | Confianza excesiva otorgada a un servicio de terceros en el mismo SSO |
| 3 | Cuenta de ChatGPT / Codex de un empleado | Toma de control de la sesión a través del SSO comprometido |
| 4 | Repositorio interno de GitHub | Apertura de una pull request a través del enlace Codex del empleado |
Claude Opus 5 como copiloto ofensivo
Hacktron usó Claude Opus 5 para explorar la superficie de ataque y encadenar las dos vulnerabilidades más rápido de lo que permitiría un análisis totalmente manual. El modelo ayudó a calificar el impacto del fallo de memoria y a mapear los servicios conectados al SSO, un trabajo que normalmente lleva mucho más tiempo a mano. Los investigadores precisan que la pull request abierta en el repositorio interno no leyó el código fuente, no fusionó ni publicó nada, y no tocó datos de clientes.
El uso de un modelo como acelerador de investigación en seguridad refleja una tendencia ya visible en otras herramientas ofensivas y defensivas, a medida que estos mismos modelos ganan autonomía en tareas de producción de larga duración mucho más allá de la investigación de seguridad.
# Esquema simplificado de un flujo de conversión de imágenes en servidor,
# el tipo de cadena que apuntaba el fallo de libheif
convert uploaded-image.heic -resize 800x800 -quality 85 output.jpg
identify -verbose uploaded-image.heic
OpenAI publicó una corrección catorce horas después del aviso, un plazo inusualmente rápido para un fallo que afecta a una autenticación compartida entre varios servicios.
Punto de atención: cualquier servicio autoalojado que delegue la conversión de imágenes en ImageMagick o en una librería de decodificación de terceros (libheif, libraw, libwebp) hereda el nivel de seguridad de esa dependencia. Una base mínima de hardening incluye mantener actualizadas estas librerías, independientemente del núcleo de la aplicación.
La respuesta de OpenAI y el calendario de corrección
OpenAI confirmó una corrección unas catorce horas después del informe inicial de Hacktron, y el 1 de septiembre pagó una recompensa de 6.500 dólares al equipo. El plazo tan ajustado contrasta con la complejidad de la cadena: el fallo afectaba a un componente de terceros poco visible, y su corrección completa suponía revisar la confianza que el SSO otorgaba a servicios externos, no solo corregir una línea de código en libheif. El caso también plantea, de fondo, preguntas sobre la llegada de modelos cada vez más autónomos a las herramientas de los equipos técnicos, tanto en el ataque como en la defensa.
Lo que hay que recordar
Una librería de decodificación de imágenes de terceros puede convertirse en la puerta de entrada de una brecha que va mucho más allá del servicio que la usa, en cuanto un inicio de sesión único compartido conecta ese servicio con sistemas más sensibles. La ayuda de un modelo como Claude Opus 5 acortó el tiempo necesario para calificar y encadenar los dos fallos, sin cambiar la naturaleza del problema de fondo: auditar las dependencias de procesamiento de archivos y mapear los servicios conectados al SSO siguen siendo los dos puntos ciegos más caros de ignorar.
Este tipo de cadena recuerda que una auditoría de seguridad que se detiene en el código de la aplicación siempre deja fuera del radar una librería de conversión de archivos. En las infraestructuras que se gestionan de forma continua, actualizar las dependencias de procesamiento de imágenes (ImageMagick, libheif, libwebp) recibe la misma prioridad que un parche del propio CMS, precisamente porque es el tipo de componente que se olvida fácilmente al hacer el inventario — Simon Janvier.
Para saber más: el relato completo en The Register.
