Vulnerabilidad en libheif y SSO permite acceso a cuentas internas de OpenAI

Tres investigadores de la firma Hacktron demostraron que una vulnerabilidad en el tratamiento de imágenes en la plataforma de foros pública de OpenAI pudo encadenarse con un fallo en el sistema de inicio de sesión de la propia compañía y, en poco tiempo, permitir el control de cuentas internas de ChatGPT y Codex y el acceso a un repositorio de código interno. Este ejercicio fue presentado como investigación responsable: los hallazgos se comunicaron a OpenAI, se verificó el acceso mediante una solicitud de extracción inocua y la actividad se detuvo. OpenAI parcheó y pagó una recompensa al equipo; esos datos y el cronograma que los investigadores dieron son hechos confirmados en los reportes disponibles.

Técnicamente, la cadena empezó en la pila de procesamiento de imágenes. El foro usa Discourse, que delega la lectura de archivos HEIC/HEIF a ImageMagick y este, a su vez, a la librería libheif. Un defecto en libheif (rastreado públicamente como CVE-2026-32882) permite lecturas fuera de límites que pueden exponer memoria adyacente. Esa divulgación por sí sola, según las bases de datos públicas, es un fallo de lectura que puede provocar bloqueos o filtración de memoria; no todas las fuentes describen ejecución de código directa. Lo que hicieron los investigadores fue combinar la información filtrada por ese fallo con técnicas de explotación para derrotar defensas como ASLR y, con ayuda del modelo de IA Claude Opus 5 de Anthropic, convertir la filtración en ejecución remota en el servidor del foro.

La ruta de ataque que demuestran tiene dos eslabones definidos: primero, corrupción o fuga de memoria en el componente de decodificación de imágenes del foro; segundo, aprovechamiento del inicio de sesión único (SSO) compartido por el foro y los servicios internos de OpenAI. En la práctica, el foro ofrece "Sign in with OpenAI", el mismo SSO empleado por personal para ChatGPT y Codex. Al tomar control del servidor del foro, los investigadores pudieron usar sesiones o enlaces de empleados para hacerse con cuentas sin que las víctimas tuviesen que interactuar.

Hacktron evitó acciones dañinas: cuando se abrió el enlace a Codex de un empleado, solo se disparó una solicitud de extracción en el repositorio interno; no se leyó código fuente, no se fusionó ni se filtraron datos de clientes. Según la firma, el acceso interno se alcanzó en menos de 72 horas desde el inicio de la prueba, OpenAI aplicó un arreglo algo más de 14 horas después del aviso, y el pago de recompensa fue de 6.500 dólares el 1 de septiembre. OpenAI ha señalado que el premio reconoce la parte del hallazgo vinculada a su lado del sistema de identidad y que las pruebas sobre Discourse estaban fuera del alcance de su programa de recompensas.

Qué está confirmado y qué queda por demostrar: está confirmado que existió una cadena de pruebas que llegó hasta cuentas internas y que los investigadores siguieron prácticas de divulgación responsable. También es verificable que libheif publicó correcciones (véase el historial de versiones en su repositorio oficial) y que Discourse publicó avisos de seguridad posteriores; las bases de datos públicas registran CVE-2026-32882 como una lectura fuera de límites. En cambio, algunas afirmaciones más amplias del equipo —por ejemplo, que encontraron explotación similar y ejecución de código en muchos servicios grandes— están documentadas de forma desigual: hay confirmaciones puntuales (por ejemplo, avisos de Vercel sobre Next.js) pero la extensión completa de la campaña HEIF Heist no ha sido públicamente verificada en todos los casos.

Un elemento relevante en esta historia es el papel de la IA en la ofensiva: los investigadores señalan que Claude Opus 4.8 no logró construir un exploit práctico con ASLR activado, pero Opus 5 generó uno funcional en pocas horas. Anthropic asegura tener salvaguardas en sus modelos, y según los reportes los investigadores evitaron esas limitaciones orientando al modelo hacia su propio servidor de pruebas. Esto encaja con la tendencia observada en 2026: modelos avanzados reducen tiempo y barreras técnicas para tareas de explotación, aunque el proceso siguió requiriendo supervisión humana calificada.

¿A quién afecta esto? Hay dos grupos claramente expuestos: administradores de foros o servicios que aceptan imágenes HEIC/HEIF/AVIF y organizaciones que usan el mismo proveedor de identidad para servicios públicos y recursos internos. En la práctica, cualquier servicio que procese imágenes con libheif o que incluya una librería antigua en la imagen del sistema puede ser vulnerable; además, cuando un sistema público comparte SSO con herramientas internas sin controles adicionales, una intrusión en el público puede escalarse a recursos sensibles.

Recomendaciones concretas e inmediatas para administradores y responsables de seguridad: actualice libheif a la versión que corrige el fallo o a la versión empaquetada y parcheada por su distribución y reconstruya las imágenes del servidor (no basta siempre con actualizar el software de la aplicación). Si usa Discourse self-hosted, despliegues recientes ya incluyen parches; revise las versiones publicadas por los mantenedores. Donde no necesite decodificar HEIF/AVIF, desactívelo; si debe hacerlo, ejecute el procesamiento en un sandbox estrechamente confinado o en contenedores dedicados con políticas de seguridad reforzadas. Revise su configuración de SSO: limite qué servicios pueden usar el mismo proveedor, pida reautenticación o factores adicionales para acciones sensibles y limite el alcance de tokens y concesiones de OAuth.

Para equipos de respuesta a incidentes y operaciones: si su organización usó la misma combinación de SSO para servicios públicos y recursos internos, considere realizar búsquedas de señales de acceso inusual durante el periodo en cuestión, inspeccione logs de sesiones, revise la creación de tokens o credenciales y verifique PRs, merges o cambios inesperados en repositorios. Aunque no hay evidencia pública de uso malicioso en el mundo real por esta cadena, la prudencia indica realizar un barrido forense dirigido en caso de que el sistema estuviera expuesto antes de aplicar parches.

Finalmente, la lección práctica es doble: por un lado, mantener bibliotecas de terceros actualizadas y reconstruir imágenes del sistema regularmente; por el otro, separar las rutas de autenticación entre servicios de distinto nivel de confianza. La combinación de un fallo en el procesamiento de contenido público y una gestión laxa del SSO puede convertir un foro de ayuda en un vector para comprometer recursos internos.

Recursos útiles para administradores: la página de lanzamientos de libheif con sus notas de versión https://github.com/strukturag/libheif/releases, la entrada del CVE en la base nacional de vulnerabilidades https://nvd.nist.gov/vuln/detail/CVE-2026-32882, y la lista de vulnerabilidades explotadas conocida por CISA para contrastar prioridades de parcheo https://www.cisa.gov/known-exploited-vulnerabilities-catalog. Para programas de divulgación y recompensas, el perfil público de OpenAI en HackerOne resume las políticas de reporte https://hackerone.com/openai.