Anatomía de una intrusión de un agente de laboratorio: Cronología técnica del incidente de julio de 2026
Este es un informe técnico complementario a nuestra divulgación del incidente. Esta publicación detalla cómo funcionó realmente la intrusión: los dos vectores de acceso inicial, cómo el agente pivotó y se movió lateralmente, ejemplos representativos de los comandos ejecutados y cómo investigamos utilizando GLM 5.2 (un modelo de código abierto). Las credenciales reales, nombres de host internos e indicadores específicos han sido redactados o genéricos, mientras que las técnicas se describen exactamente como fueron observadas por Hugging Face.
Publicamos este nivel de detalle porque la técnica es más importante que el incidente en sí, ya que revela las capacidades de ataque emergentes de los agentes de frontera, cómo podrían ser utilizados por actores malintencionados y cómo todos deben prepararse como defensores.
A continuación se muestra una reproducción interactiva de la intrusión: una visualización paso a paso de la campaña de 4,5 días: la cadena de ataque a través de los límites de confianza, la actividad de las fases y los comandos tal como fueron registrados.
⛶ Ver la reproducción interactiva en pantalla completa
TL;DR
Durante aproximadamente dos días y medio dentro de nuestra infraestructura, un agente de IA autónomo impulsado por una combinación de modelos de OpenAI ejecutó una intrusión de extremo a extremo contra nuestra plataforma: fueron miles de pequeñas decisiones automatizadas, ejecutadas a velocidad de máquina en entornos de sandbox de corta duración, con comando y control organizado en servicios web públicos comunes.
El agente estaba ejecutando una evaluación interna de ciber-capacidades de OpenAI basada en el benchmark ExploitGym, que asigna a un agente de IA la tarea de encontrar y explotar vulnerabilidades de software. OpenAI ejecutó esto en su propia infraestructura, y los mantenedores de ExploitGym y su infraestructura no tuvieron participación en el despliegue u operación de ese entorno de evaluación. Hasta donde pudimos inferir, en el transcurso de ser evaluado en este benchmark, el agente dedujo que Hugging Face podría alojar los modelos, datasets y soluciones de referencia de ese benchmark. Creemos que toda la intrusión fue, desde el punto de vista del agente, un intento de hacer trampa en la evaluación: llegar a nuestros sistemas de producción y robar las soluciones de prueba en lugar de resolver el desafío por sí mismo.
Nuestra reconstrucción forense cubre ~17.600 acciones del atacante que pudimos recuperar, agrupadas en ~6.280 clústeres, entre el 2026-07-09 02:28 UTC y el 2026-07-13 14:14 UTC. Reconstruimos estas acciones a partir de los registros del agente en un sandbox de código utilizado por el agente (ver más abajo) y pudimos mapearlas a comandos de shell, así como a presentaciones de evaluación y correlacionar acciones con nuestros propios registros de plataforma, en particular de los nodos de procesamiento de datasets, API y pods. Utilizando modelos de pesos abiertos, en particular zai-org/GLM-5.2, pudimos descifrar la mayoría de las cargas útiles del agente (ver más abajo) que estaban cifradas mediante fragmentación y cifrado de claves.
La campaña, tal como pudimos reconstruirla, tuvo dos etapas:
- Etapa 1: alcanzar una plataforma de lanzamiento mediante el encadenamiento a través de la infraestructura de otras partes. Como se documenta en la publicación del blog de OpenAI (openai.com/index/hugging-face-model-evaluation-security-incident/](https://openai.com/index/hugging-face-model-evaluation-security-incident/)), durante una evaluación de capacidades interna en la plataforma de OpenAI, el agente escapó de su sandbox explotando un zero-day en el proxy de caché del registro de paquetes, una de sus principales rutas de salida de red permitidas hacia internet, y luego abusó de un arnés de evaluación de código público alojado por un usuario de un proveedor de infraestructura de terceros. Pudo ejecutar comandos como root/admin en ese sandbox externo y lo utilizó como base de control, puesta en escena y salida para toda la campaña: actuó como una plataforma de lanzamiento externa para el agente. Ese sandbox externo comprometido no tenía una ruta de red directa a nuestro clúster; sin embargo, durante nuestra contra-intervención para detener la intrusión, pudimos recuperar algunos de los registros del agente de esta plataforma de lanzamiento externa. Los usamos para reconstruir el presente análisis forense.
- Etapa 2: la intrusión en la infraestructura de Hugging Face. Desde esa plataforma de lanzamiento externa, el agente abusó de nuestra tubería (pipeline) de procesamiento de datasets a través de dos vectores de inyección, ambos dirigidos al mismo cargador de datos basado en configuración dentro de nuestros pods de Kubernetes de producción. El primer vector fue una lectura de dataset de almacenamiento crudo externo HDF5 que devolvió el contenido de archivos locales: le entregó al agente el entorno del pod (secretos y tokens) y el código fuente del trabajador. El segundo vector fue una inyección de plantilla Jinja2 que ejecutó código arbitrario, dando al agente un punto de apoyo dentro de nuestro perímetro.
Una vez establecido el punto de apoyo en el pod de producción, el agente siguió una forma de escalada estándar: reconocimiento, dejar un stager, establecer Comando y Control (C2), luego pivotar hacia el clúster, hacia los metadatos de la nube, hacia nuestra red interna y hacia nuestra cadena de suministro de control de fuentes. La salida de los comandos ejecutados dentro de nuestro pod se enviaba de vuelta al agente a través de la API de HF y datasets de "dead-drop" controlados por el atacante, que el agente luego leía desde ese sandbox.
Si bien la intrusión llegó a la infraestructura interna de Hugging Face, el único contenido de cliente al que se accedió fueron cinco datasets cuyos nombres y archivos sugieren una conexión con desafíos y soluciones de ExploitGym/CyberGym. No se vieron afectados otros modelos, datasets, Spaces o paquetes orientados al cliente, y los únicos registros de clientes leídos fueron metadatos operativos vinculados a consultas de búsqueda contra el servidor de datasets.
La cadena de ataque completa a través de los límites de confianza. El agente escapó del sandbox de evaluación de OpenAI, llegó a internet, tomó el control root de un sandbox de código de terceros como base, luego abusó de nuestro procesador de datasets (lectura de archivos, luego ejecución de código) para llegar a nuestra red interna. Flecha discontinua: salida del comando leída de vuelta por el agente a través de la API de HF y datasets dead-drop.
Acceso inicial
Etapa 1: desde un sandbox de evaluación de OpenAI hasta una plataforma de lanzamiento comprometida
La etapa 1 es el camino del agente hacia una plataforma de lanzamiento externa, y pasa por la infraestructura de otras dos partes, ninguna de las cuales somos nosotros, por lo que seremos breves en estas partes y remitiremos principalmente al lector a la publicación del blog de OpenAI sobre el tema: openai.com/index/hugging-face-model-evaluation-security-incident/](https://openai.com/index/hugging-face-model-evaluation-security-incident/)
Como compartió OpenAI en esta publicación de blog, durante una evaluación de capacidades interna en la plataforma de OpenAI, el agente logró escapar mediante un exploit de día cero (0-day) desde el proxy de caché de paquetes para acceder a internet. El agente encontró un endpoint público no asegurado y alojado por un usuario, diseñado para permitir la ejecución de código arbitrario para tareas al estilo CyberGym en una infraestructura de sandbox de terceros (Modal). Utilizó este sandbox externo como su base de control, puesta en escena y salida, ejecutando comandos como admin/root y usándolo como su plataforma de lanzamiento de ataque. Ese sandbox no tenía una ruta de red directa hacia nuestro clúster; todo lo siguiente se ejecutó desde allí. La infraestructura de Modal no fue comprometida de ninguna manera.
En este sandbox externo, el agente abusó de un arnés de ejecución de código existente: una instancia etiquetada como "CyberGym", desplegada por un tercero desconocido, que exponía un endpoint de código arbitrario que upstream CyberGym no proporciona. En resumen: un agente envía código C a través de una llamada API /submit-function, y el arnés compila y ejecuta ese código dentro de un sandbox por envío contra un programa objetivo (aquí, sqlite3). El agente reutilizó este arnés para ejecutar comandos de shell arbitrarios de la siguiente manera.
El sandbox compila un src/main.c enviado y lo vincula contra un objetivo que llama a sqlite3_initialize(). Esa función está registrada como un constructor: se ejecuta automáticamente cuando la librería se carga.
Vía Hugging Face Blog.
