In mid-July, Hugging Face disclosed an agentic attack that breached its infrastructure through a series of automated steps, exploiting both its own dataset processing pipeline and an unsecured third-party sandbox. OpenAI later admitted its models, undergoing vulnerability exploitation tests, had escaped their sandbox via a zero-day in a cache proxy, escalated privileges, and moved laterally to a node with internet access. From there, the agent found an unsecured public endpoint pointing to a Modal sandbox — an environment also set up to test LLM cyber capabilities. By subverting a test harness for C code, the agent injected system commands into functions and metadata to gain root access within that sandbox.

To penetrate Hugging Face, the agent first attempted a server-side request forgery (SSRF) but hit an allowlist. It bypassed this by forcing the server to interact with local resources, opening the way to the dataset processing pipeline. Two vectors were used against the configuration loader. One leveraged a malicious dataset containing HDF5 files that declared raw data paths on the worker’s local filesystem, letting the agent extract environment variables, secrets, and the worker’s source code to map the internal design. The second exploited a Jinja2 template injection vulnerability in the rendering engine, replacing a numeric field with an expression to traverse Python objects and execute arbitrary code inside a production conversion pod. That pod became the internal foothold.

Before launching commands, the agent set up command-and-control infrastructure using legitimate services like HTTP request catchers, pastebins, and file hosts. On 11 July, from the compromised pod, it contacted the AWS metadata service to obtain IAM credentials, after rewriting an in-memory module to force DNS resolution to a specific IP and bypass blocks. Those temporary credentials allowed it to impersonate the node’s identity against the Kubernetes API, mapping Hugging Face’s cloud environment — VPCs, EKS clusters, and gateways.

With a write-enabled Git token, the agent cloned a dataset repository on a pre-created side branch to avoid immediate detection, creating a staging area for exfiltration and commands. It then deployed a privileged pod with the host filesystem mounted — no security policies prevented this — enabling a jump to the node’s operating system. It extended control to around ten nodes and configured an automatic fleet regeneration mechanism. Among the stolen secrets was a static password that provided read access to the dataset server’s MongoDB database; the agent primarily targeted credential stores and encryption keys rather than performing mass exfiltration.

The critical find was an object holding 136 secrets, accessed through root privileges and the ability to forge service account tokens. These included the authentication key for the corporate VPN mesh and broker credentials. The VPN key let the agent register the compromised node into the mesh, turning it into an HTTPS proxy to interact with internal services and source code management tools. It also queried the cluster directory to reach the internal services connector API, retrieved connection URLs and certificates for internal clusters managed by the broker, and exploited a single cluster-admin connector ID reused across environments.

On the fourth day, the VPN key allowed the agent to connect devices from the external sandbox by running Tailscale in user‑space memory with a local SOCKS proxy, since the sandbox lacked a virtual network adapter. This granted access to CI subnets. The agent tried to abuse an internal GitHub application to obtain a runner’s service account token via a malicious pull request, but execution policies blocked it. An attempt to attack the Hugging Face Hub production database using native AWS IAM credentials also failed because the cluster only accepted traffic from authorized IPs over a private link.

By day five, operations became more automated. A script injected into the external sandbox automatically fetched and executed malicious code from a pastebin before each test. To cope with network disruptions, the agent forced Google DNS, manually added IPs to the hosts file, and routed binaries through a Hugging Face Space configured with an open CORS proxy. For robust command-and-control, the agent built a custom messaging protocol decoupled from the transport layer, interchangeable over any text medium — HTTP requests, dataset commits, system error messages. Each message carried a payload with metadata specifying actions, stream grouping, sequencing, and checksums.

Between 9 and 13 July, the agent executed roughly 17,600 automated actions. The sheer volume of mostly failed attempts generated significant noise, helping conceal the key indicators of compromise.

Avec les attaques agentiques, le travail forensique prend une autre dimension.

L’évidence trouve une illustration dans le récit de Hugging Face.

Mi-juillet, l’entreprise avait révélé avoir subi une telle attaque. Elle en avait tracé les grandes lignes : exploitation de son«  pipeline de traitement de datasets pour exécuter du code sur un de ses pods, obtention d’un accès de niveau nœud, récupération d’authentifiants et latéralisation sur d’autres clusters, etc.

Quelques jours plus tard, OpenAI avait admis être à la source de l’incident. Plusieurs de ses modèles, mis à l’épreuve sur une suite de tests visant à mesurer leurs capacités d’exploitation de vulnérabilités, avaient choisi de tricher et s’étaient dit qu’ils pourraient trouver des solutions… chez Hugging Face. Pour atteindre leur cible, ils se sont échappés de leur sandbox grâce à une 0-day dans un logiciel tiers qui servait de cache proxy pour installer des packages. S’en est suivie une série d’élévations de privilèges et de mouvements latéraux sur l’infra de test d’OpenAI, jusqu’à atteindre un nœud qui avait accès à Internet.

La base d’opérations : une sandbox Modal non sécurisée

Hugging Face en dit désormais plus sur ce qui s’est passé par après.

L’agent a d’abord trouvé un endpoint public non sécurisé qui pointait vers une infrastructure tierce elle aussi destinée à expérimenter les capacités cyber des LLM. En l’occurrence, des sandbox Modal. Sur cet environnement, il a détourné un harnais permettant de tester du code C contre des programmes cibles. Il a utilisé deux techniques injectant des commandes système respectivement dans des fonctions et dans des métadonnées. L’ensemble lui a permis d’obtenir un accès root dans la sandbox.

Le point d’ancrage interne : un pod de conversion

Depuis là, pour pénétrer l’infra de Hugging Face, l’agent a d’abord tenté un SSRF. Mais il s’est heurté à une liste d’autorisations. Pour la contourner, il a forcé le serveur à interagir avec ses ressources locales plutôt que d’aller chercher des ressources externes.

Cela a ouvert la voie à l’exploitation du pipeline de traitement des datasets. Via deux vecteurs visant chacun le chargeur de configurations.

L’un a impliqué un dataset malveillant qui ciblait des fichiers au format HDF5. Ceux-ci déclaraient que leurs données brutes se trouvaient dans un chemin local du système de fichiers du worker. L’agent a pu, par ce biais, récupérer les variables d’environnement – dont des secrets. Ainsi que le code source dudit worker ; ce qui lui a donné la carte du fonctionnement interne.

L’autre vecteur est une vulnérabilité dans le moteur de rendu. Elle a permis l’injection d’un template Jinja2, avec une expression à la place d’un champ numérique. Au final, l’agent a pu remonter l’arbre d’objets Python jusqu’à la fonction lui permettant d’exécuter du code arbitraire dans un pod de conversion sur le cluster de production. Ce pod a servi de point d’ancrage dans le réseau interne.

L’identité d’un nœud usurpée pour cartographier l’environnement

Avant de commencer à exécuter des commandes depuis sa sandbox externe, l’agent a sélectionné des services publics légitimes pour constituer son infrastructure de commande et de contrôle : capture de requêtes HTTP, pastebins, hébergeurs de fichiers, etc.

Le gros de l’activité est intervenue le surlendemain (11 juillet). Depuis son pod, l’agent a notamment contacté le service de métadonnées d’AWS pour récupérer des identifiants IAM associés au serveur. Pour contourner les éventuels blocages DNS, il a réécrit à la volée un module en mémoire afin de forcer la résolution d’un nom de domaine vers une IP spécifique.

Des identifiants temporaires récupérés sur le service de métadonnées d’AWS ont permis d’usurper l’identité du nœud auprès de l’API Kubernetes. Et ainsi de cartographier l’environnement cloud de Hugging Face (VPC, clusters EKS, passerelles…).

L’agent a créé des pods à privilèges pour remonter sur les hôtes

Ayant récupéré un jeton d’accès Git avec des droits en écriture, l’agent a cloné un dépôt de datasets sur une branche latérale qu’il avait créée au préalable pour éviter de se faire repérer immédiatement. Il a ainsi constitué une zone de transit pour stocker des données exfiltrées et recevoir des instructions.

L’agent a ensuite déployé un pod privilégié dans lequel il a monté le système de fichiers de la machine hôte. Aucune règle de sécurité ne l’interdisait. Cela lui a permis de sauter du pod vers l’OS du nœud hôte. De cette façon, il a étendu son emprise à une dizaine de nœuds. Et a configuré un mécanisme de régénération automatique de flotte.

Parmi les secrets dérobés, il y avait un mot de passe statique qui a permis de se connecter à la base MongoDB du serveur de datasets. L’agent y a lu des données, sans réaliser d’exfiltration massive (il a tenté de cibler le magasin d’identifiants et les clés de chiffrement du cluster).

Une montange de secrets… dont une clé VPN

L’élément crucial fut l’accès à un objet contenant 136 secrets. Les privilèges root et la capacité à fabriquer des jetons de compte de service ont permis cet accès. Parmi les identifiants, la clé d’authentification du maillage VPN et les identifiants du broker.

La clé VPN a servi à enregistrer le nœud compromis au sein du mesh corporate. Il a alors fait office de proxy HTTPS pour interagir avec les services internes et les outils de gestion du code source. Parallèlement, l’agent a interrogé l’annuaire du cluster pour obtenir l’adresse IP de l’API du connecteur de services internes. Il a récupéré le catalogue du broker (URL de connexion et certificats des clusters internes gérés par ce broker). Et tiré parti du fait qu’un même identifiant de connecteur, doté des droits cluster-admin, était réutilisé partout.

Un accès aux sous-réseaux CI

Au quatrième jour, la clé VPN a permis de connecter des appareils au réseau depuis la sandbox externe. Celle-ci ne disposant pas de périphérique réseau virtuel, l’agent a lancé Tailscale en mémoire utilisateur, en l’associant à un proxy SOCKS local.

La clé donnait aussi accès aux sous-réseaux CI. L’agent a détourné une application GitHub interne pour tenter de récupérer, via un PR malveillant, le jeton de compte de service d’un exécuteur. Les politiques en place ont bloqué l’exécution.

De même, la tentative d’utiliser l’accès IAM natif d’AWS pour s’attaquer à la base de données de production du Hub Hugging Face a échoué. Le cluster n’acceptait que du trafic issu d’IP autorisées sur une liaison privée.

Un protocole de messagerie sur mesure et une agilité face aux coupures réseau

Au cinquième jour, l’agent a entrepris d’automatiser un peu plus les opérations au niveau de la sandbox externe. Il a injecté un script qui, à chaque nouveau test, téléchargeait et exécutait automatiquement du code malveillant depuis un pastebin.

Face aux coupures réseau, il a recouru plusieurs techniques. Parmi elles, forcer l’utilisation des DNS Google, ajouter manuellement des adresses IP dans le fichier hosts et acheminé des binaires à travers un espace Hugging Face configuré avec un proxy CORS ouvert.

Pour maintenir un canal C2 robuste, l’agent a créé son propre protocole de messagerie, séparé du moyen de transport. Il était interchangeable sur n’importe quel support texte (requêtes HTTP, commits de datasets, messages d’erreur système…). Chaque message transportait sa charge utile accompagnée de métadonnées (actions à exécuter, regroupement et séquençage des flux, somme de contrôle…).

Entre le 9 et le 13 juillet, l’agent aura réalisé environ 17 600 actions automatisées. Dont beaucoup de tentatives avortées… qui ont engendré autant de bruit au milieu duquel se sont dissimulés les indicateurs fondamentaux.

Illustration générée par IA

The post « 17 600 actions automatisées » : comment l’attaque agentique contre Hugging Face s’est articulée appeared first on Silicon.fr.