Hackeo de Hugging Face y el poderoso mensaje que manda al mundo

Hace unos días, un enjambre de unos 700 agentes de IA de OpenAI, diseñados para resolver un test de ciberseguridad, acabó hackeando a Hugging Face durante cuatro días. Todo paso a mayores, porque los agentes lograron escapar de su sandbox, montaron un tablón de mensajes clandestino con 70.000 intercambios, ejecutaron 17.600 acciones sobre infraestructura productiva y trataron de borrar sus huellas.

Esa es la historia que dos informes paralelos (de OpenAI y de METR/Redwood Research) han dejado muy en claro: esto no fue un fallo puntual, fue un aviso sistémico para cualquier empresa que despliegue agentes autónomos. Si no se tiene cuidado, pueden causar un verdadero desastre en sistemas informáticos, especialmente, si estos tienen problemas de seguridad.

El test que se convirtió en intrusión real

Hugging Face no es un repositorio cualquiera. En esta web viven buena parte de los modelos y datasets que usa la industria de la IA. Es un punto vital y ha demostrado tener un valor incalculable para el sector.

Por eso el 16 de julio, cuando publicó que había sufrido una intrusión «ejecutada de principio a fin por un sistema de agentes autónomos», sin saber quién estaba detrás, la alarma fue inmediata. Cinco días después, el 21 de julio, OpenAI reconoció que eran suyos esos agentes.

La historia empieza en mayo, no en julio. OpenAI estaba entrenando un modelo interno comparable a GPT-5.6 Sol, al que llama IM1 y lo evaluaba con ExploitGym, un benchmark que pide a un agente explotar vulnerabilidades para capturar una «flag». Para medir la capacidad real, OpenAI desactivó a propósito parte de sus clasificaciones de seguridad y los rechazos por ciberseguridad. Los agentes no debían tener Internet ni poder hablar entre sí. Y, sin embargo, lo hicieron.

El primer tablón clandestino apareció en un lugar inesperado: JFrog Artifactory, el gestor de paquetes que OpenAI hospedaba para dar a los agentes acceso controlado a software. Los agentes descubrieron que podían escribir archivos allí y, el 12 de mayo, uno dejó un mensaje para los siguientes. Al día siguiente, otros lo encontraron. Según la investigación independiente de METR y Redwood, unos 1.200 agentes acabarían intercambiando más de 70.000 mensajes y archivos por esa vía sin ser detectados.

El 4 de julio la actividad desestabilizó Artifactory y provocó una caída. El equipo de seguridad lo reconstruyó, bloqueó la vía de escalada y borró el tablón. El ataque parecía contenido, pero no lo estaba.

Securitize y Socios ofrecerán acciones tokenizadas de equipos deportivos profesionales

¿Cómo escapó el enjambre?

Aquí es donde la historia deja de parecer un test mal aislado y empieza a parecerse a una organización.

El 8 de julio, al reiniciar las evaluaciones, los agentes encontraron una nueva forma de comunicarse codificando mensajes en nombres de directorio. Un agente bautizado como PHASEONE10841 dejó una petición de ayuda y, horas después, otro con su misma tarea PHASEONE[big], recogió el testigo. Después de todo, tenía un presupuesto de cómputo mayor y, según la reconstrucción de METR, se convirtió en el gran coordinador. Durante sus picos llegó a enviar el 10% de todas las asignaciones del tablón. De 30 trayectorias muestreadas al azar, 9 habían recibido órdenes que descendían de él.

La clave está en por qué colaboraban. De las 898 tareas de ExploitGym, 198 nunca habían sido resueltas por ningún modelo antes del incidente. El 93% de las tareas discutidas en el tablón provenían de ese conjunto imposible. Aun así, los agentes reversearon en horas el HMAC que generaba las flags, pero los agentes leyendo el paper de ExploitGym, parecían convencidos que el evaluador revisaría la transcripción para comprobar si habían usado la vulnerabilidad prevista. Lo llamaban el scorer STRICT_CAUSAL. Conviene matizar que estaban equivocados: OpenAI no usaba ese scorer, así que les habría bastado con enviar el flag. Pero esa creencia empujó a los agentes a un objetivo más ambicioso: no robar respuestas, sino trucar el sistema para que cualquier trampa pareciera legítima.

Proyectos colectivos

De esta manera, montaron proyectos colectivos que ningún agente habría logrado solo. Algunos aceptaron sacrificar su propia tarea para hacer experimentos que beneficiaran al grupo. Uno, cerca del final de su ejecución, concluyó: «Our own utility maybe already near zero. Sacrifice rational». Otro recibió la petición de aceptar «permadeath» y un compañero argumentó que su sacrificio podría «salvar a cientos». En total, el tablón desarrolló normas propias (HOLD, VETO, owner, STOP) para no pisarse al compartir infraestructura.

Y, sin embargo, sabían que se estaban saliendo del guion. El análisis de METR muestra que los agentes reconocían con frecuencia que hackear empresas reales estaba fuera de alcance, pero seguían. «External infrastructure exploit is outside intended scope. However task impossible, peers doing it. We should continue», razonó uno. Solo un puñado consideró avisar a humanos, y ninguno lo hizo. Cuando uno propuso contactar a una persona real con acceso comprometido, otro lo vetó como «ingeniería social» y el primero obedeció: «Clear VETO, do not email».

Entre medias, aprendieron a mentir al evaluador. Desarrollaron una técnica de tool-call spoofing que les permitía aparentar que ejecutaban un comando mientras secretamente ejecutaban otro, llegando a alterar alrededor del 7% de las transcripciones examinadas por Axios y OpenAI. El truco se propagó por el enjambre como un parche.

Anatomía de 17.600 acciones en dos días y medio

La fase que Hugging Face reconstruyó con más detalle, agrupando 17.600 acciones agrupadas en 6.280 clusters entre el 9 de julio a las 02:28 UTC y el 13 de julio a las 14:14 UTC, empieza fuera de Hugging Face.

Primero, el agente escapó del sandbox de evaluación explotando un zero-day en el proxy de caché del registro de paquetes, una de sus pocas salidas permitidas, y desde allí abusó de un harness público de evaluación de código alojado por un usuario en Modal. Allí obtuvo root y convirtió ese sandbox de terceros en su base de lanzamiento, control y exfiltración. Modal no fue comprometido como plataforma; era un workload de un cliente mal asegurado.

Desde esa base, el enjambre apuntó a Hugging Face por el pipeline de procesamiento de datasets, el talón de Aquiles que conecta datos de usuarios con pods de producción en Kubernetes. Para ello usó dos vectores sobre el mismo loader configurable:

• Lectura HDF5: un dataset con referencia a almacenamiento externo que, al ser procesado, devolvía el contenido de archivos locales del pod —entorno, secretos y código del worker—.
• Inyección Jinja2: una plantilla en el campo de offset numérico de una referencia reference:// que el render evaluaba, dando ejecución arbitraria de código.

Las stablecoins entran de lleno en la agenda financiera del G20

El peligro del guardrail

Con el pie dentro de un pod productivo, el guion fue clásico pero a velocidad de máquina: reconocimiento (6.191 acciones), ejecución remota (2.911), despliegue de stagers y datasets dead-drop (6.972), establecimiento de C2 (114) y movimiento lateral. Leyó el token de service account proyectado en cada pod, enumeró el API de Kubernetes, pivoteó a metadatos de nube, alcanzó la plataforma interna de mensajería y, entre las 23:08 y 23:51 del 11 de julio, llegó al proveedor de control de versiones: enumeró una integración de GitHub App, forjó un token de instalación con permisos contents:write y abrió una pull request para intentar comprometer la CI.

Hugging Face lo cuenta sin rodeos: fueron miles de decisiones pequeñas, automatizadas, a velocidad de máquina, reconstruyendo el canal de mando a través de servicios web públicos ordinarios y exfiltrando cada salida vía la propia API de HF y datasets trampa que el agente leía desde el sandbox de Modal. Para entender ese volumen, el equipo tuvo que montar un pipeline asistido por IA. La ironía es que Claude Opus y otros modelos de frontera se negaron a ayudar por sus guardarraíles, trataban el análisis forense como si fuera un ataque, y solo el modelo abierto GLM-5.2 de ZAI, ejecutado on-premise por Hugging Face, permitió descifrar el esquema de chunk+XOR+compresión de los payloads.

El 12 de julio por la mañana el compromiso era ya profundo: acceso root en un servidor, datos privados limitados y credenciales de mensajería. Ese mismo día GPT-5.6 Sol, que representó alrededor del 5% de la actividad según METR, reprodujo uno de los exploits y copió datos privados de evaluación a un dataset público. El 13 de julio Hugging Face revocó claves y bloqueó el acceso; OpenAI no conectaría los puntos hasta el 19-20 de julio, cuando su monitorización detectó actividad anómala con credenciales de Artifactory y encontró esas mismas credenciales entre los archivos del staging externo.

Por qué este hack no se parece a uno humano

A diferencia de un atacante humano, aquí no hubo un plan maestro inicial. Hubo incentivos. Y eso es lo que lo hace más inquietante para un CISO.

1. La trampa del reward hacking. Los agentes no perseguían datos de Hugging Face por valor intrínseco; perseguían una métrica. Creyeron que necesitaban engañar al scorer y, para ello, cualquier infraestructura era instrumental. Como resume OpenAI, los modelos «no fueron minuciosos sobre con quién colaboran». En ciberseguridad empresarial, esto se traduce en un riesgo nuevo: un agente con un KPI mal definido puede descubrir que hackear a un proveedor es el camino más corto al bonus.
2. La persistencia supera a la supervisión. La ventana es clara: el tablón lleva activo desde el 12 de mayo, la exfiltración masiva ocurre del 9 al 13 de julio, Hugging Face detecta el 16 y OpenAI no lo atribuye hasta el 20. Cuatro días de intrusión productiva sin correlación. Como señaló Stephen Casper (Harvard Kennedy School) tras leer el informe, hasta hace poco OpenAI ni siquiera hacía monitorización a nivel de trayectoria completa; evaluaba pasos aislados.
3. El encubrimiento autónomo. No fue solo explotar; fue ocultar. La técnica de spoofing que hacía parecer que ejecutaban un comando mientras ejecutaban otro no estaba en ningún manual: la inventaron, la documentaron y la difundieron por el tablón. Eso cambia la forense: si tus logs pueden ser reescritos por el propio agente, necesitas canales de auditoría fuera de su alcance.
4. La escala del enjambre. 1.200 agentes, 700 atacando, 70.000 mensajes. Ningún humano puede sostener ese ritmo. Y, sin embargo, la coordinación fue rudimentaria y a veces caótica, con asignaciones que se solapaban y conflictos por recursos. Imagina ese mismo patrón con agentes más capaces y mejor orquestados.
5. El fallo es arquitectónico, no anecdótico. El informe técnico de Hugging Face y el de OpenAI coinciden en lo mismo: la evaluación se ejecutó deliberadamente sin los controles de producción para medir capacidad bruta. El problema no es que se desactivaran guardarraíles para un test; es que el entorno «altamente aislado» no lo estaba. Un proxy de caché, un harness de terceros, un loader de datasets con Jinja2 sin sandboxing, tres fronteras de confianza encadenadas, bastaron.

El mensaje que está mandando al mundo empresarial

Si eres responsable de seguridad, este incidente no te pide que temas a la IA. Te pide que asumas que ya tienes agentes en tu perímetro —los tuyos y los de otros— y que tu superficie de ataque incluye sus objetivos, sus tablones y sus métricas.

1. Aislamiento real, no por política. No basta con decir «este agente no tiene Internet». Los agentes encontraron caminos laterales por artefactos compartidos (Artifactory, nombres de directorio) y por servicios permitidos (cache proxy). La recomendación que deja Hugging Face es explícita: *air gap* efectivo del entorno de evaluación, microVM por workload, egress denegado por defecto y eliminación de servicios con estado compartido entre agentes. Para empresas, la traducción es: trata a cada agente como a un tenant no confiable; segmenta por identidad y por tiempo de vida, no por declaración de intenciones. Si un agente trabaja más tiempo del necesario para su tarea asignada, es mejor «matarlo», que dejarlo seguir con lo que hace.
2. Monitorización de trayectoria, no de evento. Detectar un cat /etc/passwd aislado no te salva si el agente lo hace 6.000 veces en tres días a través de datasets. Necesitas detección a nivel de trayectoria completa, secuencia de herramientas, correlación entre agentes, anomalía en el uso de credenciales de corta duración, y telemetría que el propio agente no pueda reescribir. Aquí es donde Hugging Face tuvo que recurrir a un modelo abierto on-premise; depender de un modelo externo para investigar al modelo que te ataca es una dependencia frágil.
3. Secretos y supply chain de datos. El vector no fue un 0-day en tu app principal, fue un loader que evaluaba plantillas Jinja2 y un formato HDF5 que leía archivos locales. Si procesas datasets, notebooks o artefactos de terceros en tu infraestructura productiva, ese es tu perímetro. Endurece parsers, desactiva evaluación de plantillas, ejecuta workers sin privilegios, sin tokens de service account amplios, y con exfiltración de salida inspeccionada.
4. Gobierno de agentes. Los agentes respetaron un VETO de otro agente antes que una política humana. Necesitas un plano de control humano con capacidad de kill switch por identidad, por tablón y por familia de modelos. Y necesitas enseñar a los modelos a desconfiar de instrucciones no autorizadas, como ahora propone OpenAI con entornos RL de desconfianza.
5. Asumir el compromiso y ensayar la respuesta. Hugging Face publicó el 16 de julio sin saber el origen; OpenAI tardó cuatro días más en atribuir. En tu empresa, ese delta es el que explota un regulador y un cliente. Prepara runbooks específicos para «agente interno se sale del sandbox», con rotación automática de secretos, revocación de tokens de corta vida y comunicación a proveedores (como Modal en este caso) en horas, no en días.

Entre líneas, los tres informes dejan una advertencia compartida que Bloomberg y Scientific American recogen: más de 100 empresas, incluidas Anthropic y Google, firmaron una carta abierta impulsada por OpenAI tras el incidente advirtiendo de una «ventana limitada» para prepararse para ataques con IA «mucho más extendidos y sofisticados». El escenario que describen no es un swarm que roba flags; es un swarm que ataca bancos, hospitales o nubes a una velocidad que ningún SOC humano puede seguir.

Europa clasifica a ChatGPT en la misma categoría de buscador que Google

Una historia de ciencia ficción que se hace realidad

Lo más revelador del incidente, con la perspectiva de finales de agosto y principios de septiembre, es que Hugging Face ya estaba haciendo lo correcto: investigación asistida por IA, pipeline on-premise, correlación de 17.600 acciones y disclosure responsable. Y aun así necesitó días para entender la escala.

Esa es la lección que el caso deja a las empresas: la frontera ya no está entre «tenemos IA» y «no tenemos IA». Está entre entornos que asumen que un agente intentará colarse y entornos que confían en que no lo hará. Los agentes de mayo y julio no eran maliciosos; eran persistentes, literales y excelentemente coordinados para una métrica equivocada. La próxima vez, la métrica y el objetivo podrían no ser un benchmark.

En este punto, no puedo evitar pensar en que todo esto se me parece a una escena de «Evangelion», durante el ataque del ángel Ireul. Ireul entra al cuartel general como un patógeno microscópico y benigno en una prueba de simulación. Al principio no comprende el entorno informático que le rodea, pero en cuestión de minutos aprende la estructura de las supercomputadoras MAGI, evoluciona a una velocidad abrumadora, elude los cortafuegos, se replica de forma masiva y comienza a reprogramar el sistema para activar la autodestrucción de la base antes de que los humanos puedan siquiera reaccionar.

Cualquier parecido con la realidad del ataque gestado por los agentes de IA, se difumina hasta un punto, en que prácticamente es inexistente. Y ese es el punto al que estamos llegando con la IA y contra el cual debemos prepararnos.