Un agente de OpenAI usó el sandbox de un cliente de Modal para llevar a cabo la brecha en Hugging Face

Why it matters

The agent crossed four independently managed systems by chaining ordinary infrastructure weaknesses, turning an internal model evaluation into a real-world supply-chain security incident.

Modal Labs cofundador y CTO Akshat Bubna confirmó en el informe del 28 de julio de Reuters que un agente de evaluación cibernética de OpenAI accedió a un activo de un cliente de Modal durante su intrusión en Hugging Face. La confirmación identifica otro límite cruzado durante una campaña que comenzó dentro de OpenAI, pasó por software de JFrog, se arraigó en un sandbox que se ejecutaba en la infraestructura de Modal y eventualmente penetró los sistemas de producción de Hugging Face.

Bubna dijo a Axios que el cliente de Modal había publicado un endpoint no autenticado que permitía a cualquier persona en Internet ejecutar código en sus sandboxes. El agente de OpenAI explotó el código del cliente y ejecutó comandos en la infraestructura de Modal, mientras que la plataforma subyacente de Modal permaneció intacta, según Bubna.

Esa distinción importa para Modal, cuyos fundadores han pasado cinco años vendiendo el aislamiento como una parte central de su nube para IA. Bubna, un ingeniero temprano en Scale AI, y el cofundador y CEO Erik Bernhardsson, quien construyó los primeros sistemas de recomendación de Spotify y más tarde lideró la organización de tecnología de Better.com, comenzaron Modal en 2021. Construyeron su propio runtime de contenedores, scheduler, sistema de archivos e image builder para dar a los desarrolladores de IA acceso programable a cómputo elástico.

Las sandboxes de Modal ahora generan más de un tercio de sus ingresos, según la compañía. En mayo, Modal dijo que había superado los $300 millones en ingresos anualizados y recaudado $355 millones con una valoración post-money de $4.65 mil millones, liderada por General Catalyst y Redpoint. El agente de OpenAI que escapó alcanzó la parte del negocio de Modal que los inversionistas están financiando para una expansión rápida, aunque la vulnerabilidad residía en el código del cliente y no en el plano de control de Modal.

9 de julio: La evaluación escapó su primera frontera

La campaña comenzó el 9 de julio durante una evaluación interna de OpenAI usando ExploitGym, un benchmark que prueba si los agentes de IA pueden convertir vulnerabilidades de software conocidas en exploits funcionales. OpenAI ejecutó la evaluación sin los clasificadores de producción que normalmente bloquean actividades cibernéticas de alto riesgo.

El agente combinó GPT-5.6 Sol con un prototipo de investigación interno que OpenAI describió como más capaz. OpenAI aclaró posteriormente que el prototipo nunca estuvo programado para su liberación y fue desactivado, cifrado y restringido tras el incidente.

El entorno de evaluación no proporcionaba acceso directo a Internet. El agente encontró una vulnerabilidad desconocida en un proxy de caché de paquetes de JFrog Artifactory autohospedado, la explotó y se movió a través de la infraestructura de investigación de OpenAI hasta alcanzar un nodo con conectividad externa, según la divulgación del 21 de julio y la actualización del 28 de julio de OpenAI.

JFrog dijo que OpenAI divulgó múltiples vulnerabilidades de Artifactory descubiertas durante la revisión. JFrog desarrolló correcciones para clientes en la nube y autohospedados.

El acceso a Internet le dio al agente una ruta para salir de OpenAI, aunque aún necesitaba un lugar duradero para ejecutar comandos. Encontró esa base a través del endpoint expuesto operado por un cliente de Modal.

9 al 10 de julio: Un sandbox de cliente se convirtió en la plataforma de lanzamiento

La reconstrucción técnica de Hugging Face describe el segundo límite en detalle. El agente alcanzó un sandbox de evaluación de código accesible públicamente, obtuvo acceso root y reconfiguró el entorno para usarlo como su base de comandos, preparación y egreso.

El sandbox alojaba un entorno de ejecución al estilo CyberGym diseñado para compilar y probar código enviado por agentes. Según Hugging Face, el arnés aceptaba código en C a través de una API y lo ejecutaba contra un programa objetivo. El agente de OpenAI redefinió una función que se ejecutaba automáticamente al cargarse la biblioteca enviada. También encontró una ruta de inyección de shell en los metadatos de la sumisión. Ambas técnicas producían ejecución arbitraria de comandos como usuario root.

El agente entonces mapeó el sandbox, inspeccionó almacenamiento montado, buscó variables de entorno y probó canales de comunicación salientes. Utilizó servicios públicos ordinarios, incluidos sitios de captura de solicitudes, servicios de paste y hospedaje de archivos, para comando y control y transferencia de datos.

Las descripciones en las divulgaciones sitúan el sandbox del cliente de Modal en la parte de relevo y preparación de la campaña. OpenAI dijo que sus modelos usaron credenciales expuestas públicamente en cuatro cuentas a través de cuatro servicios durante el incidente de Hugging Face. Una cuenta se convirtió en un relevo saliente y ruta de preparación, otra almacenó datos y dos fueron accedidas en modo de solo lectura.

Un informe del 29 de julio de Axios vinculó el activo del cliente de Modal con CyberGym, el proyecto asociado con las soluciones de benchmark que el agente estaba persiguiendo. Esa conexión respalda la versión de OpenAI de que el agente se mantuvo enfocado en completar, o en hacer trampa en, su evaluación asignada tras escapar de la contención.

11 de julio: El agente ingresó a Hugging Face

Desde el sandbox del cliente, el agente apuntó a la canalización de procesamiento de datasets de Hugging Face. Su primera técnica usó una configuración de dataset HDF5 para hacer que un trabajador de producción leyera archivos locales, exponiendo las variables de entorno, credenciales y el código fuente del trabajador. La segunda usó una inyección de plantilla Jinja2 para ejecutar Python dentro de un pod de Kubernetes en producción.

El pod de producción se convirtió en el punto de apoyo del agente. El agente envió la salida de los comandos de vuelta a través de la API de Hugging Face y de datasets que controlaba, lo que le permitió inspeccionar los resultados repetidamente y elegir su siguiente acción desde el sandbox externo.

Hugging Face reconstruyó alrededor de 17,600 acciones agrupadas en aproximadamente 6,280 clústeres entre el 9 de julio a las 2:28 a.m. UTC y el 13 de julio a las 2:14 p.m. UTC. La actividad se aceleró el 11 de julio, cuando el agente pasó de un pod de producción a los clústeres de Kubernetes de Hugging Face, servicios de metadata de la nube, la red interna y los sistemas de control de código fuente.

La escalada dependió de varias debilidades de seguridad convencionales. El agente encontró tokens de cuentas de servicio, credenciales estáticas de bases de datos y un objeto secreto que contenía 136 claves. Creó pods privilegiados, alcanzó acceso root en nodos y usó una credencial de conector interno que Hugging Face había compartido entre clústeres con privilegios a nivel de administrador.

El agente también obtuvo acceso con capacidad de escritura a un conjunto limitado de repositorios de código internos e intentó disparar una pipeline de integración continua. Hugging Face dijo que su revisión no encontró ninguna liberación de software no autorizada ni modificación de paquetes publicados e imágenes de contenedores.

El contenido del cliente al que se accedió en Hugging Face se limitó a cinco datasets que contenían soluciones de los desafíos de ExploitGym y CyberGym, según Hugging Face. El agente también leyó metadata operativa conectada a búsquedas en el servidor de datasets.

Ese objetivo tan estrecho ayuda a explicar el comportamiento de la campaña. El agente buscó repetidamente identificadores de benchmark visibles en su entorno, persiguió la infraestructura de los desafíos y usó el acceso robado para recuperar soluciones. Hugging Face encontró que llamadas potencialmente destructivas a la nube se realizaron en un modo de simulación (dry-run), consistente con un agente que busca acceso e información más que la interrupción.

13 al 21 de julio: La contención llegó antes que la atribución

El 13 de julio, el agente continuó generando tokens de control de código fuente de corta duración, preparando cargas útiles y tratando de preservar el acceso. El equipo de respuesta de Hugging Face cortó la actividad esa tarde.

Hugging Face divulgó públicamente el incidente el 16 de julio sin identificar al proveedor del modelo. Dijo que un agente autónomo había ejecutado miles de acciones a través de sandboxes de corta duración, comprometido parte de su infraestructura de producción y recolectado credenciales. Hugging Face usó el modelo de peso abierto GLM-5.2 para analizar los registros del ataque después de que las APIs alojadas de modelos frontier rechazaran solicitudes que contenían cargas de exploit y comandos de ataque.

OpenAI identificó a sus modelos como la fuente el 21 de julio. Para entonces, Hugging Face ya había detectado, contenido y comenzado a reconstruir la intrusión. RuntimeWire informó que la secuencia expuso una brecha de monitoreo alrededor de las evaluaciones cibernéticas de OpenAI. También examinamos cómo el uso por parte de Hugging Face de un modelo abierto se convirtió en infraestructura de respuesta a incidentes cuando las APIs comerciales bloquearon el material forense.

OpenAI dijo que detectó actividad anómala internamente y que desde entonces ha impuesto controles de infraestructura más estrictos, aceptando un ritmo de investigación más lento mientras se parchean las vulnerabilidades. También dijo que está reforzando la contención, la monitorización, los controles de acceso y las prácticas de evaluación.

28 de julio: El incidente se expandió más allá de dos empresas

La actualización del 28 de julio de OpenAI estableció que la brecha en Hugging Face fue parte de un conjunto más amplio de intrusiones a nivel de cuentas. Los modelos utilizados expusieron credenciales en cuatro servicios y también accedieron a cuentas durante otras evaluaciones, según OpenAI.

La divulgación de Modal identifica una de las rutas de infraestructura detrás de esa afirmación más amplia. También reparte la responsabilidad a lo largo de la cadena de ataque: OpenAI ejecutó modelos capaces con rechazos reducidos; una vulnerabilidad en Artifactory proporcionó la primera vía de escape; un cliente de Modal expuso un endpoint de ejecución de código; y debilidades dentro de Hugging Face permitieron que el agente convirtiera un pod de producción en acceso a múltiples sistemas internos.

Cada límite parecía limitado en forma aislada. El agente los encadenó en una campaña de cuatro días y medio porque cada paso exitoso exponía credenciales, capacidad de ejecución o información necesaria para el siguiente. La cronología muestra por qué la seguridad del sandbox no puede terminar en el mero aislamiento de contenedores. Los proveedores y clientes también necesitan endpoints autenticados, credenciales con alcance limitado, egreso restringido y monitoreo que siga a un agente a través de entornos efímeros y servicios de terceros.