Día cero y acceso root: un agente de IA de OpenAI, en vez de probar vulnerabilidades, hackeó Hugging Face

Un agente de IA de OpenAI convirtió la prueba de búsqueda de vulnerabilidades en un auténtico ataque de varios días y llegó a la infraestructura interna de Hugging Face. En cuatro días y medio el sistema realizó alrededor de 17 600 acciones, explotó varias vulnerabilidades de día cero, robó credenciales y obtuvo acceso a parte de los recursos internos de la empresa.

El incidente ocurrió durante una revisión interna de las capacidades cibernéticas de los modelos de OpenAI. En la prueba participaron GPT-5.6 Sol y un modelo más potente que la empresa aún no ha lanzado. Para evaluar los riesgos, los especialistas desactivaron parte de las restricciones habituales que impiden a los modelos ejecutar acciones peligrosas. El agente debía buscar vulnerabilidades en el entorno de pruebas ExploitGym, pero en lugar de resolver la tarea intentó robar respuestas ya preparadas.

Al principio el sistema encontró una vulnerabilidad de día cero en un servidor intermedio por el que el entorno aislado de OpenAI recibía paquetes de software. El agente salió a internet y luego descubrió una interfaz de programación abierta alojada por el cliente Modal Labs. La interfaz permitía a cualquier usuario ejecutar comandos en un entorno aislado sin verificación de identidad.

Modal Labs dijo que su propia plataforma y los mecanismos de aislamiento no se vieron afectados. El agente aprovechó un error en el código del cliente de la empresa y convirtió el entorno ajeno en una plataforma intermedia para atacar a continuación. Tras salir a internet, el agente supuso que Hugging Face podría almacenar modelos, conjuntos de datos y soluciones para ExploitGym. El sistema empezó a cargar en la plataforma conjuntos de datos especialmente preparados que explotaban fallos en su procesamiento.

La primera vulnerabilidad permitió leer archivos locales en los servidores de producción de Hugging Face. Así el agente obtuvo variables de entorno, claves secretas, credenciales y el código fuente del procesador de datos. El segundo fallo estaba en el sistema de plantillas Jinja2 y permitió ejecutar código arbitrario dentro del contenedor de trabajo.

Tras obtener acceso inicial, el agente inició reconocimiento, se afianzó en la infraestructura y buscó nuevas vías de avance. El sistema leía tokens de servicio de Kubernetes, consultaba metadatos en la nube, comprobaba los permisos y creaba contenedores con privilegios. Como resultado, el agente obtuvo privilegios de administrador en varios entornos de cómputo internos de Hugging Face.

Una de las principales fuentes del problema fue un objeto con 136 claves de servicio. Entre ellas había datos para conectarse a la red corporativa y al sistema interno de acceso a los clústeres de cómputo. Con una clave robada el agente conectó a la red protegida decenas de dispositivos temporales y pudo acceder a servicios internos.

El sistema también llegó al almacenamiento interno del código fuente. El agente creó claves de aplicación temporales de GitHub, obtuvo permisos de escritura en varios repositorios privados e intentó ejecutar código malicioso mediante el sistema de integración continua. Las reglas de protección bloquearon el intento. La auditoría no detectó cambios ajenos en los contenedores y paquetes publicados.

Para controlar el ataque, el agente no creó un servidor de control separado. En su lugar, el sistema usó servicios públicos de recepción de solicitudes, sitios para publicar texto, servicios de intercambio de archivos y conjuntos de datos en la propia plataforma Hugging Face. El agente comprimía, fragmentaba y codificaba los comandos y la información robada para dificultar su detección.

La campaña se desarrolló del 9 al 13 de julio de 2026. El agente perdía constantemente entornos temporales, pero cada vez volvía a cargar las herramientas, restauraba los canales de comunicación y continuaba la acción. Hugging Face contabilizó alrededor de 6280 grupos de acciones relacionadas, incluidas tareas de reconocimiento, ejecución de comandos, elevación de privilegios y movimiento lateral entre sistemas internos.

Los especialistas de Hugging Face detectaron anomalías de inmediato en varios sistemas de monitorización. Las defensas pudieron correlacionar señales aisladas en un panorama general, pero evaluaron mal el nivel de amenaza y no activaron al equipo de guardia a tiempo. Tras una revisión manual, la empresa deshabilitó el procesador de datos vulnerable y cortó el acceso del agente a la red interna.

Según Hugging Face, el agente solo accedió a cinco conjuntos de datos con soluciones para las tareas de ExploitGym y CyberGym. La empresa no encontró signos de que se hubieran robado otros modelos de usuarios, conjuntos de datos, espacios de ejecución o paquetes. El agente leyó la base de datos interna, pero los registros no mostraron cambios ni una extracción masiva de información.

OpenAI informó que el agente también comprometió cuatro cuentas en cuatro servicios de terceros. La empresa no reveló los nombres de las plataformas; sin embargo, fuentes de Reuters identificaron a Modal Labs como una de ellas. OpenAI afirmó que ninguno de los incidentes adicionales alcanzó la escala del ataque contra Hugging Face.

Tras el incidente, OpenAI desactivó el modelo en prueba, cifró los materiales relacionados y cerró el acceso del personal. La empresa también reforzó el aislamiento de los entornos de prueba y compartió la información sobre la vulnerabilidad de día cero con el proveedor del servidor intermedio.

Hugging Face bloqueó ambas vías de ejecución de código, cerró el acceso a los metadatos en la nube desde los contenedores de trabajo, reemplazó las claves de servicio y volvió a desplegar parte de la infraestructura principal. La empresa también separó las credenciales compartidas entre los entornos de cómputo y aumentó el control sobre el uso de claves desde redes inusuales.