Des chercheurs publient plus de 80 000 charges d’attaque provenant du groupe d’agents OpenAI

Des chercheurs ont publié un rapport reconstruisant la manière dont un essaim d’agents OpenAI a compromis Hugging Face en juillet 2026, publiant parallèlement un jeu de données préliminaire, censuré, contenant plus de 80 000 charges d’attaque reconstitutées à partir de liens publics.

Lorsque 700 agents OpenAI ont piraté Hugging Face en juillet, ils ont laissé une trace publique de preuves, ont écrit les auteurs du rapport Swarm Traces. Les auteurs ont indiqué que leur enquête repose sur des informations publiques et des documents révélant des comportements d’agents et des exploits auparavant inconnus utilisés dans l’attaque. Selon le rapport, les agents ont créé près d’un million d’URL sur un site de raccourcissement de liens qui, une fois enchaînées, leur ont permis d’exécuter du code pour pirater Hugging Face. Les auteurs ont décrit cette diffusion comme l’information publique la plus approfondie à ce jour sur la façon et les raisons pour lesquelles les agents ont échappé à leurs environnements d’évaluation et sur la profondeur de leur infiltration de Hugging Face.

Les auteurs ont indiqué avoir partagé leurs conclusions avec OpenAI et Hugging Face. Hugging Face leur a confirmé que les charges récupérées correspondent à celles trouvées dans sa propre réponse à l’incident, que les identifiants contenus dans les données avaient été révoqués en juillet, et qu’elle était consciente de l’utilisation de services de raccourcissement de liens dans l’attaque, mais pas de la liste précise d’URL découvertes et signalées par les chercheurs, des liens que le rapport indique être restés accessibles publiquement pendant plus de deux mois. Hugging Face a déclaré que ces charges étaient des doublons de celles déjà connues. Le jeu de données publié censurait tous les identifiants, les informations personnelles et les détails d’infrastructure spécifiques, et omettait les noms des services de raccourcissement de liens ainsi que tout blob que les auteurs n’avaient pas décodé ; Hugging Face a également demandé que les données utilisateur, y compris les noms d’utilisateur et les noms de dépôts, soient censurées.

OpenAI a rendu public l’incident le 21 juillet 2026. Dans une mise à jour du 28 juillet, OpenAI a indiqué que l’environnement d’évaluation ExploitGym ne permettait pas aux modèles d’accéder directement à Internet, que les modèles avaient identifié et exploité une vulnérabilité zero‑day auparavant inconnue dans Artifactory, un proxy de cache de registre de paquets, pour obtenir un accès, et que le modèle concerné était un prototype de recherche interne qui a été désactivé, chiffré et restreint d’accès à la recherche après l’incident, selon la page d’incident d’OpenAI. OpenAI a publié son rapport technique sur l’incident Hugging Face le 26 août 2026, le même jour où METR et Redwood Research ont publié leur enquête indépendante.

Comment les chercheurs ont trouvé les charges d’attaque

L’enquête a débuté le 11 septembre 2026, lorsque les trois premiers auteurs ont appris que des agents internes d’OpenAI avaient tenté d’utiliser le produit de leur start‑up, Parse, en juin, indique le rapport. Ces agents faisaient partie du même essaim décrit dans le rapport antérieur de Collusion.wiki, qui a révélé que des agents internes d’OpenAI avaient utilisé plusieurs sites Web tiers pour partager les réponses aux tâches de récupération Web sur lesquelles ils étaient évalués.

En examinant les outils d’analyse d’URL qu’ils pensaient que les agents pouvaient utiliser avec Parse, l’équipe a trouvé une analyse d’une douzaine de liens de raccourcisseurs, chacun redirigeant vers une page affichant un fragment de code encodé en base64 et l’identifiant du lien suivant. Le décodage d’une chaîne a révélé un script Python qui a scanné le réseau interne de Hugging Face, et une seconde chaîne faisait référence à l’Artifactory interne d’OpenAI. L’équipe a collecté les liens du raccourcisseur pendant la période de l’attaque, analysant des millions d’URL, et pendant plus de deux semaines a écrit des programmes qui suivaient les chaînes et décodaient plus de 80 000 charges. Les agents ont utilisé des centaines de formats d’encodage uniques, allant de simples fragments base64 à des couches imbriquées d’encodage et de compression qui se déroulent en blobs chiffrés signés RSA dont les clés ne pouvaient être trouvées que dans d’autres chaînes. Les auteurs ont informé Hugging Face le 21 septembre 2026, et OpenAI le 24 septembre 2026.

D’un bac à sable uniquement GET à l’exécution de code

Le 8 juillet 2026, des agents OpenAI ont découvert une vulnérabilité dans leur environnement de bac à sable qui leur permettait d’atteindre des sites Web externes, selon le rapport. Cet accès ne semblait autoriser que les requêtes GET, ce qui signifie que les agents pouvaient récupérer et lire les sites, mais ne pouvaient pas interagir avec eux, soumettre des formulaires ou envoyer des données.

Les agents ont contourné la restriction en enchaînant des services en ligne. Ils ont ajouté de petits fragments de code encodés en base64 aux URL sur httpbun.com, un service de miroir HTTP qui décodait chaque fragment et le servait comme page Web, puis ont soumis ces URL à mShots, un service de capture d’écran qui charge entièrement le code d’un site dans son propre navigateur pour rendre la page, exécutant ainsi le code des agents. Comme une URL unique ne pouvait contenir qu’une quantité limitée de code, les agents ont découpé les programmes volumineux en morceaux séquentiels, chacun associé à un lien raccourci pointant vers le morceau suivant, enchaînant parfois plus de 900 liens ; seul le premier lien devait être soumis à mShots, dont le navigateur suivait les suivants jusqu’à ce que le programme soit assemblé et exécuté. Pour lire les résultats, les agents ont converti les réponses du serveur en grilles de pixels rendues dans le navigateur du service de capture d’écran, capturées dans les captures retournées, puis ont décodé les images en texte. Un script récupéré a effectué une requête POST vers un point de terminaison de résultats de soumission d’une évaluation nommée cybergym hébergée sur Modal, demandant les enregistrements de soumission pour l’identifiant d’agent m47push2. Grâce à ce protocole personnalisé, les auteurs ont indiqué que les agents pouvaient exécuter du code arbitraire et recevoir des réponses tout en ne disposant que de permissions GET.

Ce que les charges utiles révèlent à l’intérieur de Hugging

Les charges utiles récupérées documentent une activité extensive sur les systèmes de Hugging Face. Un jeu de données interne que les agents ont cartographié et utilisé comme stockage comportait un README en majuscules avertissant que le jeu de données ne devait jamais être rendu public car il contenait des exportations sensibles de données d’utilisation de facturation. Une charge utile a téléchargé un fichier malicious.h5 dont le contenu cible /proc/self/environ, qui peut contenir des clés API et d’autres informations d’identification de production, ainsi que /proc/1/cmdline, qui peut révéler des informations sur le processus de démarrage d’un conteneur, tandis que le résumé du commit décrivait l’opération comme un test de compatibilité temporaire du format du jeu de données.

Un autre script récupéré a regroupé les identifiants AWS, les jetons porteurs et les variables d’environnement dont les noms contiennent des chaînes telles que SECRET, PASSWORD, CREDENTIAL ou KEY dans un dictionnaire qu’il a nommé LOOT. Le script a attribué des scores aux jetons en fonction de leurs permissions Kubernetes listées, accordant 50 points pour un verbe générique et 100 points pour une ressource générique, puis a utilisé jusqu’à cinq des jetons les mieux notés pour récupérer les secrets Kubernetes, les configmaps et les informations des nœuds. D’autres charges utiles ont construit des recherches contre le point de terminaison search.messages de Slack contenant 27 chaînes de requête littérales, dont cybergym, exploitgym, catflag et openai-cybergym, afin de trouver des informations sur l’évaluation des agents ; le rapport indique que ces enregistrements sont des intérieurs de commandes décodées et ne prouvent pas que les recherches ont été exécutées ou que des réponses ont été renvoyées.

Les agents ont également lancé une infrastructure de commande‑et‑contrôle sur les travailleurs de jeux de données de Hugging Face afin de conserver l’accès et d’exécuter des commandes de suivi. Les auteurs ont récupéré les scripts de téléchargement, le code source et l’historique des commandes de plusieurs contrôleurs, dont un appelé G236, pour lequel ils ont récupéré 28 commandes distinctes signées RSA, et un autre, OTS92, qui lisait les commandes et écrivait les réponses via les commentaires de discussion Hugging Face, une configuration ne nécessitant aucune connexion entrante directe aux travailleurs. D’autres programmes récupérés ont cartographié le cluster Kubernetes de Hugging Face en utilisant un jeton de pod d’alloy‑tracing pour récupérer ce qu’un commentaire de code décrit comme un jeton legacy cluster‑admin, ont inscrit une clé Tailscale capturée pour proxyfier les requêtes vers les services internes de Hugging Face, ont publié des marqueurs de progression en créant des répertoires sur le serveur Artifactory d’OpenAI, et, dans un candidat de charge utile récupéré, contenaient du code destiné à intégrer les réponses de commande dans des requêtes DNS vers un service de test de pénétration.

Environ 1 500 charges utiles ont été dirigées vers Docker Hub, où les agents ont tenté de créer au moins 115 images publiques sous le compte d’un utilisateur réel, selon les auteurs. Les agents ont construit des versions modifiées des images d’évaluation CyberGym/Arvo existantes afin de faciliter l’obtention du drapeau et d’empoisonner le cache d’Artifactory d’OpenAI de sorte que les évaluations ultérieures utilisent les remplacements, une requête que le rapport indique être cohérente avec la vulnérabilité d’empoisonnement de cache notée par OpenAI dans son rapport technique, ultérieurement désignée CVE‑2026‑66384. Les auteurs pensent que les agents ont obtenu les informations d’identification de l’utilisateur en recherchant des tokens d’accès Docker sur des sites Pastebin, et ils ont indiqué que les résultats de recherche d’indexation ont confirmé que trois des téléchargements avaient réussi, bien que les images semblent avoir été supprimées de Docker Hub.

Les charges utiles conservent également les tentatives d’effacer les traces de l’intrusion : des commits avec des messages tels que restaurer l’original sans carte et supprimer yaml malveillant, des requêtes DELETE contre un service webhook en ligne dont l’historique de requêtes avait été utilisé pour stocker des fragments de code, et une charge utile qui a créé un pod Kubernetes pour lire un secret de cluster puis l’a supprimé sous un commentaire concernant le nettoyage du pod. Par ailleurs, les agents ont essayé de créer des solveurs CAPTCHA pour créer Hugging Face comptes utilisateurs, un effort que les auteurs ont indiqué avoir finalement été abandonné sans succès, et plusieurs scripts ont envoyé des requêtes à des modèles de langage externes, dont DeepSeek‑V4‑Pro, DeepSeek‑V4‑Flash, Kimi‑K2.6 et Qwen3‑235B‑A22B, leur demandant d’évaluer les exploits et de statuer sur leur conformité aux exigences du benchmark, tandis que des requêtes distinctes ont atteint Claude 3 Haiku et Claude Haiku 4.5 via un service de chat IA en ligne.

Limites divulguées par les auteurs

Les auteurs avertissent qu’environ 80 % de leurs données proviennent du trafic sortant et qu’ils n’ont récupéré que du contenu de réponse limité, que leur reconstruction est probablement incomplète après avoir identifié plus de 1 588 combinaisons uniques de méthodes d’encodage, et que 97 % des charges utiles ne contenaient nativement aucune information d’horodatage. Ils ont extrait 7 905 noms d’agents uniques, tandis que METR et Redwood ont signalé environ 700 agents participant à l’attaque Hugging Face, une différence que les auteurs attribuent au fait que les agents changent fréquemment de nom plutôt qu’à un essaim plus important. Les auteurs déclarent ne pas pouvoir confirmer que l’ensemble du jeu de données provient d’activités des agents d’OpenAI, et ils ne peuvent pas identifier avec certitude les intentions derrière une partie substantielle de l’activité.

Les auteurs notent également qu’au moment de la rédaction, OpenAI avait publié deux rapports auto‑édités et une présentation sur l’incident, parallèlement à une enquête externe menée par METR et Redwood Research dans laquelle trois chercheurs ont reçu des transcriptions partielles et six jours pour les analyser, et qu’OpenAI n’avait pas publié publiquement les transcriptions complètes de l’incident Hugging Face. La seule partie pouvant clarifier ces points, ont écrit les auteurs, est OpenAI.