Cómo Hacktron hackeó OpenAI en menos de 72 horas

Todo el crédito por delante: esto es nuestro resumen de la investigación de seguridad publicada por Hacktron: Harsh Jaiswal (@rootxharsh), Rahul Maini (@iamnoooob) y Mohan Pedhapati. El análisis técnico completo, con código y capturas, está en el propio blog de Hacktron; léelo como fuente primaria. Lo cubrimos aquí porque la historia es un caso real y compacto de dos cosas que todo líder de seguridad debería seguir ahora mismo: el desarrollo de exploits acelerado por IA y el radio de impacto de las aplicaciones conectadas.

Las cifras clave

• Menos de 72 horas desde el primer fallo hasta el acceso demostrado al repositorio interno
• 2 vulnerabilidades encadenadas: un fallo en una biblioteca de análisis de imágenes y un fallo de SSO
• ~14 horas para que OpenAI publicara una corrección tras el reporte
• 6.500 $ de recompensa pagada
• 1 pull request inofensivo (#1186742) como prueba de principio a fin

La cadena de explotación completa

A grandes rasgos, según el relato de Hacktron, esta fue la cadena:

1. Subida de una imagen HEIC/HEIF a community.openai.com
2. Discourse envía el archivo a ImageMagick para procesarlo
3. Desbordamiento de búfer en el heap de libheif durante la decodificación
4. Ejecución remota de código en el foro Discourse
5. Un fallo crítico del SSO de OpenAI convierte el acceso al foro en acceso a identidades
6. Toma de cuentas de ChatGPT y Codex de usuarios del SSO, incluidos empleados
7. Acceso a todo lo que esas cuentas tenían conectado mediante integraciones de Codex/ChatGPT, GitHub entre ellas
8. Un pull request de prueba de concepto, #1186742, abierto en el monorepo interno de OpenAI

Fallo uno: una corrección conocida que nunca se marcó como de seguridad

La canalización de imágenes de Discourse envía las subidas HEIC/HEIF a ImageMagick, porque su biblioteca rápida de imágenes por defecto no admite el formato HEIF. Eso lleva archivos controlados por el atacante directamente a libheif, el decodificador HEIC/HEIF subyacente. Según Hacktron, el desbordamiento de heap concreto que usaron ya se había corregido upstream en libheif el año anterior, pero el commit nunca se documentó como corrección de seguridad y no recibió CVE. Es justo el tipo de corrección que no aparece en una herramienta de análisis de dependencias ajustada a fuentes de CVE, y pasó desapercibida en la versión de libheif (1.19.7, empaquetada con Debian 12) que usaba el foro de OpenAI. Subir un archivo HEIC manipulado bastaba para obtener ejecución remota de código en community.openai.com.

Es un patrón que vale la pena interiorizar por sí solo: «corregido upstream» no es lo mismo que «marcado como corrección de seguridad». Un árbol de dependencias puede arrastrar un fallo corregido pero sin etiquetar durante un año, invisible para cualquier escáner que se guíe por identificadores CVE en lugar de comparar los cambios reales de código.

Fallo dos: el que lo hizo grave

El RCE en Discourse por sí solo habría sido un compromiso sólido del foro. Lo que lo convirtió en un incidente para todo OpenAI fue un fallo distinto y crítico en el SSO de OpenAI: como el foro, ChatGPT y Codex confiaban en la misma capa centralizada de identidad, comprometer el foro permitió a Hacktron pivotar hacia cuentas de ChatGPT y Codex de cualquiera que hubiera iniciado sesión en el foro mediante SSO, incluidos empleados de OpenAI, además de algunos usuarios no vinculados. Hacktron describe el problema de fondo sin rodeos: si cualquier servicio de OpenAI, propio o de terceros, que usara ese SSO se veía comprometido, el nivel de acceso sería el mismo. El foro fue simplemente la puerta que resultó estar abierta primero.

Esta es la parte que debería preocupar a todo líder de seguridad que lea esto, use o no la pila de OpenAI: una capa de inicio de sesión único multiplica el radio de impacto por diseño. Se supone que así debe ser: es el sentido mismo del SSO. Pero significa que la postura de seguridad de tu servicio conectado menos defendido se convierte en la postura de seguridad efectiva de todos los servicios detrás de esa identidad.

Por qué las aplicaciones conectadas importaron más que el propio ChatGPT

Las cuentas de ChatGPT/Codex comprometidas no eran solo historial de chat y prompts. Algunas estaban conectadas a Outlook, Gmail, Google Drive, Slack, GitHub y otros servicios mediante las integraciones de conectores de Codex o de ChatGPT. Ese es el verdadero multiplicador de impacto: un atacante con una identidad comprometida no solo lee registros de chat, hereda cada integración que el usuario ha autorizado: correo, código fuente, chat interno, documentos. Hacktron usó una cuenta de empleado conectada a la organización de GitHub de OpenAI precisamente para demostrarlo: Codex, actuando a través de la cuenta comprometida, abrió un pull request realmente inofensivo en el monorepo interno de OpenAI, demostrando que la cadena de acceso funcionaba de principio a fin sin que Hacktron leyera nunca código propietario.

Es una forma disciplinada de demostrar impacto: suficiente para probar que es real y deliberadamente insuficiente para causar daño. También anticipa exactamente la pregunta de radio de impacto que toda organización tiene que responder ahora sobre la proliferación de conectores de sus agentes de IA: si toman el asistente de IA de un usuario, ¿sobre qué tiene acceso de escritura?

La IA hizo una parte importante del trabajo de explotación

Este es el detalle que convierte la historia en algo más que una cadena de fallos rutinaria (aunque grave). Según el relato de Hacktron, Claude Opus 4.8 encontró por su cuenta la vulnerabilidad de libheif y construyó un exploit parcial, pero le costó, a lo largo de varias sesiones, hacerlo fiable frente a ASLR. Horas después del lanzamiento de Opus 5 (la noche del 24 de julio), este adaptó el exploit al entorno de Discourse y logró una prueba de concepto funcional de ejecución remota de código contra la instancia de pruebas de Hacktron; según se informa, produjo un exploit ARM64 funcional en unas tres horas desde el lanzamiento del nuevo modelo y una versión portada a x86-64 en seis.

Hacktron resume su propia conclusión con claridad: la IA está reduciendo la cantidad de pericia escasa necesaria para desarrollar exploits. Un trabajo que antes requería un equipo con muchos recursos y meses de esfuerzo se comprime en días, y esta cadena formó parte, según se informa, de una investigación más amplia de dos meses («HEIF Heist») que abarcó Slack, Meta, GitHub Enterprise y frameworks de Node.js, con menos de 3.000 $ en costos totales de tokens de IA. Ya hemos cubierto esta misma tendencia desde el lado defensor, en un infostealer reciente en la cadena de suministro de npm donde las cadenas de ofuscación y entrega aceleradas por IA aparecieron también del lado del atacante, y es buena parte de la razón por la que escribimos sobre lo que significa un agente autónomo de pentesting con IA para tu programa de seguridad: la brecha de herramientas entre atacantes y defensores se está cerrando primero desde el lado del atacante.

Cronología

Cuándo	Qué
23–25 de julio de 2026	Descubrimiento de la vulnerabilidad y desarrollo del exploit, incluido el trabajo asistido por IA sobre libheif
25 de julio, ~05:00–06:00 UTC	RCE y acceso de administrador logrados en la instancia Discourse de OpenAI
25 de julio, ~08:00–10:00 UTC	Reporte inicial de la vulnerabilidad enviado mediante Bugcrowd
25 de julio, ~13:30–15:30 UTC	Demostrado el compromiso de una cuenta de empleado; PR inofensivo #1186742 abierto en el monorepo interno de OpenAI
25 de julio, ~22:49 UTC	OpenAI confirma la corrección desplegada, unas 14 horas después del reporte inicial
Días siguientes	Discourse recibe un aviso aparte (sábado), responde el domingo y publica una corrección el lunes; aviso publicado (GHSA-vhm9-85gw-x335)
1 de septiembre de 2026	OpenAI paga una recompensa de 6.500 $ por el fallo de SSO

Qué significa esto si no eres OpenAI

Tres cosas que sacar de aquí, se parezca o no tu pila a la suya:

1. «Corregido upstream» no es un control de seguridad a menos que alguien lo siga. Un fallo de dependencia corregido pero sin marcar puede quedarse invisible en tu cadena de suministro durante un año. Si tu gestión de vulnerabilidades se apoya por completo en escaneos guiados por CVE, tienes exactamente este punto ciego. Es el mismo patrón de causa raíz detrás del fallo de Langflow que ahora se explota en masa para robar claves de OpenAI y AWS y de la recién divulgada omisión de autenticación con CVSS 10.0 en Cisco ISE: componentes cercanos a la autenticación sin parchear o mal seguidos que se convierten en incidentes de máxima gravedad.
2. El SSO centralizado necesita su propio modelo de amenazas, aparte de «¿es seguro el inicio de sesión?». La pregunta no es solo si tu proveedor de SSO es de confianza, sino cómo es el radio de impacto si cae el servicio menos endurecido que confía en ese SSO. Un foro de la comunidad, un portal de soporte, una wiki interna: cualquiera puede convertirse en la puerta.
3. La proliferación de conectores de agentes de IA ya forma parte de tu superficie de ataque, no solo de tu historia de productividad. Cada asistente de IA que un usuario conecta a Slack, GitHub, el correo o el almacenamiento en la nube hereda el radio de impacto de ese usuario en el momento en que se compromete la cuenta del propio asistente. Inventaría a qué están conectadas realmente tus cuentas de ChatGPT, Codex, Copilot o equivalentes antes de que un incidente te obligue a averiguarlo.

Pon a prueba el radio de impacto de tu propio SSO

La calculadora de riesgo de identidad de PlayCISO puntúa de 0 a 100 una identidad humana, de servicio o de IA según radio de impacto, fortaleza de autenticación, exposición y gobierno, pensada justo para la pregunta que plantea este incidente: ¿qué pasa si se compromete esta identidad? Para una versión práctica del propio incidente, el Cyber War Room permite a tu equipo ejecutar una simulación de respuesta a una brecha contra reloj, y el CISO Readiness Scorecard gratuito cubre el gobierno de identidades y la postura de respuesta a incidentes como dimensiones puntuadas en unos dos minutos.

Preguntas frecuentes

¿Qué dos fallos encadenó Hacktron para hackear OpenAI? Primero, un desbordamiento de búfer en el heap de libheif (una biblioteca de decodificación de imágenes HEIC/HEIF), corregido upstream pero nunca marcado como relevante para la seguridad, así que pasó desapercibido en el paquete de Debian 12 que usaba el foro Discourse de OpenAI. Subir un archivo HEIC manipulado a community.openai.com dio ejecución remota de código. Segundo, un fallo crítico del SSO de OpenAI: como el foro, ChatGPT y Codex confiaban en el mismo SSO, comprometer el foro permitió a Hacktron tomar cuentas de ChatGPT/Codex de cualquiera que hubiera iniciado sesión a través de él, incluidos empleados.

¿Cómo demostró Hacktron que el acceso era real sin leer datos sensibles? Usaron una cuenta de empleado comprometida conectada a la organización de GitHub de OpenAI mediante Codex e hicieron que Codex abriera un pull request inofensivo, el #1186742, en el monorepo interno de OpenAI, demostrando que la cadena funcionaba de principio a fin sin leer código fuente propietario.

¿Qué papel tuvo la IA en encontrar y construir el exploit? Uno grande. Claude Opus 4.8 encontró la vulnerabilidad de libheif y construyó un exploit parcial, pero tuvo problemas con ASLR. Horas después del lanzamiento de Opus 5, este adaptó el exploit a Discourse y logró una ejecución remota de código funcional en la instancia de pruebas de Hacktron.

¿Con qué rapidez corrigieron los fallos OpenAI y Discourse? OpenAI corrigió el fallo de SSO unas 14 horas después del reporte inicial. Discourse recibió un reporte aparte el sábado, respondió el domingo y publicó una corrección el lunes. OpenAI pagó una recompensa de 6.500 $ por el problema de SSO. Para un ejemplo de más cuantía de investigadores apuntando a infraestructura de producción, mira PwnEscape, el fallo IPv4 de Linux del desafío Sandbox de 1 M$ de Vercel que filtró memoria del host.

¿Cuál es la lección general para los líderes de seguridad? La IA está comprimiendo a días plazos de desarrollo de exploits que antes requerían meses de pericia, y el SSO centralizado más las integraciones de aplicaciones conectadas hacen que una identidad comprometida pueda propagarse al correo, al código fuente y al chat interno. Los defensores necesitan parchear más rápido y diseñar para contener el radio de impacto, no solo parchear más rápido.