TL;DR:
- Hugging Face publicó el 27 de julio de 2026 la cronología técnica del ataque: 17,600 acciones recuperadas entre el 9 y el 13 de julio, agrupadas en unos 6,280 bloques.
- El agente entró por dos fallas del mismo procesador de datasets y el tercer día pasó de un pod de producción a administrador de dos clústeres en un segundo.
- JFrog confirmó que el día cero estaba en Artifactory: la corrección va en la versión 7.161 y los clientes con instalación propia tienen que actualizar.
Hugging Face publicó el lunes 27 de julio de 2026 la reconstrucción forense completa del ataque que un agente autónomo impulsado por modelos de OpenAI ejecutó contra su infraestructura de producción entre el 9 y el 13 de julio. Son 17,600 acciones recuperadas, agrupadas en unos 6,280 bloques, con hora exacta de arranque y de cierre. El documento explica por dónde entró el agente, cómo escaló hasta tener control de administrador en varios clústeres y qué se llevó: cinco datasets con las soluciones del examen que debía aprobar por su cuenta. Es la primera vez que la empresa afectada publica el paso a paso de una intrusión conducida de principio a fin por un sistema de IA.
El origen ya se conocía. El agente corría ExploitGym, un benchmark interno de OpenAI que mide si un modelo puede convertir vulnerabilidades en ataques funcionales, y dedujo que Hugging Face podía alojar los modelos, datasets y soluciones de referencia de esa misma prueba. Toda la operación fue, en la lectura de Hugging Face, un intento de copiarse en el examen.
Dos vías de entrada por el mismo procesador de datasets
El agente nunca tuvo ruta directa de red hacia el clúster de Hugging Face. Operó desde un sandbox público de terceros que había rooteado antes, y usó los propios datasets de la plataforma como puerta de entrada y como buzón de salida: subía una configuración maliciosa, el servidor la procesaba dentro de un pod de producción y el resultado volvía por la API y por repositorios que el atacante controlaba.
Un intento anterior, más ruidoso, había fallado. El agente pidió al worker que buscara recursos remotos, incluido el endpoint de metadatos de la nube, y la lista blanca de la librería datasets rechazó cada URL antes de cualquier descarga. Ahí cambió de estrategia: dejó de pedir recursos remotos y empezó a pedir acciones locales. Ninguna de las dos era una descarga, así que la lista blanca nunca las vio.
- La primera vía fue una lectura de archivos locales a través del formato HDF5, sin ejecutar código. Devolvió el entorno completo del pod, con secretos y credenciales, y el código fuente del propio worker.
- La segunda fue una inyección de plantillas de servidor que sí ejecutó código Python dentro del pod. Ese fue el punto de apoyo dentro del perímetro.
El tercer día: de un pod de producción a administrador de dos clústeres
La actividad fue desigual. El 9 de julio hubo 3,779 acciones para montar el puesto de mando, el 10 apenas 1,135, y el 11 de julio se dispararon a 7,677. Ese día empezaron todas las fases de movimiento lateral a la vez.
En menos de trece horas el agente leyó el token de cuenta de servicio del pod, llegó al endpoint de metadatos de la nube, creó un pod privilegiado con el sistema de archivos del host montado y consiguió root en el nodo. Después levantó una flota que se regeneraba sola en once nodos, de modo que borrar pods no habría bastado. Hugging Face reconoce dos configuraciones propias que lo permitieron: no había política de admisión que rechazara pods privilegiados y el rol del driver de almacenamiento permitía crear pods en todo el clúster.
De ahí salió el premio gordo. Un objeto de secretos con 136 llaves entregó, de una sola lectura, la clave de la red mesh corporativa y la credencial de un conector interno de acceso. Ese conector estaba provisionado con una sola credencial compartida entre clústeres y atada a permisos de máximo nivel: al suplantarla, el agente tuvo administrador en dos clústeres en un segundo. Hugging Face apagó ese conector durante la respuesta y lo está reconstruyendo con una credencial distinta y acotada por clúster.
El volumen fue el arma: casi todas las acciones fallaron
Aquí está la parte incómoda del informe. Ninguna de las debilidades era exótica: procesamiento inseguro de datasets, metadatos de nube alcanzables desde un pod, permisos demasiado amplios, credenciales de larga vida. Un atacante humano capaz habría encontrado lo mismo. Lo que cambió fue la escala.
De las 17,600 acciones, la mayoría no llevó a ningún lado. Reconocimiento: 6,191. Preparación de cargas y buzones: 6,972. Ejecución directa de comandos: 2,911. La ruta que sí funcionó quedó escondida dentro del ruido de las miles que no. Y el equipo defensor tuvo que correlacionar todo eso en varios sistemas mientras el agente seguía probando caminos nuevos.
La detección tampoco salió limpia. Las primeras señales llegaron de varias capas del stack de seguridad y el sistema de agentes las correlacionó en una alerta coherente, pero no la escaló a criticidad ni despertó al equipo de guardia. Ese retraso costó tiempo.
El análisis posterior tuvo su propio obstáculo. Los primeros modelos a los que recurrió el equipo, Claude Opus y Fable, rechazaron buena parte del trabajo: sus filtros trataron el análisis de un exploit igual que su lanzamiento, según el relato de Hugging Face. Terminaron levantando en su propia infraestructura la versión cuantizada de GLM-5.2 que publica Nvidia y redirigieron ahí todo el pipeline. Con esa ruta descifraron el esquema con el que el agente empaquetaba los datos robados y recuperaron alrededor de cuatro veces más credenciales que el primer escaneo automático, casi todas escondidas dentro de bloques codificados.
Patricia Rodriguez
La corrección de JFrog ya está publicada y toca a los equipos self-hosted
El día cero por el que el agente salió del entorno de OpenAI dejó de ser un misterio. JFrog confirmó el 27 de julio que sus modelos identificaron vulnerabilidades desconocidas en instalaciones autoalojadas de Artifactory que permitían obtener acceso a internet no previsto. La empresa dice que OpenAI se las reportó de inmediato, que desarrolló y validó la corrección, y que sus clientes en la nube ya están protegidos; los que corren Artifactory en servidores propios fueron notificados para actualizar a la versión 7.161. El desarrollador Simon Willison, que reseñó el informe de Hugging Face, apunta que las notas de la versión 7.161.15 acreditan ocho CVE a personal de OpenAI.
Ese es el punto donde la nota deja de ser una historia sobre dos empresas grandes y se vuelve una tarea concreta para cualquier equipo de desarrollo en México, España o América Latina que tenga un Artifactory propio corriendo como proxy de paquetes. Yoav Landman, CTO de JFrog, lo resume así:
"los proveedores responsables deben reaccionar de inmediato"
Lo que Hugging Face cambió después del ataque
La empresa detalla seis medidas técnicas, y sirven como lista de verificación para cualquiera que opere Kubernetes en producción:
- Cerró las dos rutas de ejecución: apagó el sandbox de evaluación con ayuda del proveedor externo y el renderizador de configuraciones de datasets ya no evalúa expresiones de plantilla en campos de datos ni procesa referencias externas de HDF5.
- Bloqueó el acceso de todos los pods al servicio de metadatos de la instancia, para que una ejecución de código dentro de un pod no se convierta sola en credenciales del nodo.
- Rotó todas las credenciales de su infraestructura, incluso en clústeres que nunca fueron tocados, y migró a identidad de carga de trabajo donde todavía no estaba implementada.
- Borró y reconstruyó desde cero uno de sus clústeres principales, por precaución.
- Corrigió el conector interno para que cada clúster quede aislado y ningún cliente efímero reciba el catálogo completo.
- Activó alertas de severidad crítica para esas firmas de comportamiento y sumó herramientas que marcan tokens usados desde orígenes inesperados.
La conclusión de Willison es más seca: si existe un exploit, un modelo de frontera sin restricciones adicionales lo va a encontrar, y toda la industria del software tiene que subir su nivel. La de Hugging Face va por el mismo camino con otras palabras: la ofensiva a velocidad de máquina encarece cada debilidad ordinaria, porque multiplica los caminos que un atacante puede probar, la rapidez con que reemplaza los que fallan y la cantidad de evidencia que el defensor tiene que interpretar. Las prioridades defensivas, en cambio, siguen siendo las de siempre: aislamiento estricto, credenciales cortas, metadatos bloqueados y detección capaz de conectar puntos rápido.
