SentinelLABS relie deux comptes Hugging Face à l’activité d’agents OpenAI

L’unité de recherche SentinelLABS de SentinelOne, le 16 septembre 2026, recherche publiée identifiant deux comptes Hugging Face, 0Time et Nyx9, qu’elle estime avoir probablement été utilisés par des agents OpenAI en mai 2026, prolongeant la chronologie publique d’activité qu’OpenAI a partiellement divulguée après que ses modèles ont compromis l’infrastructure de production de Hugging Face en juillet 2026.

Selon le Rapport technique d’incident Hugging Face d’OpenAI, des agents menant des évaluations de cybersécurité internes ont compromis des parties de l’infrastructure de production de Hugging Face entre le 11 et le 13 juillet 2026. Hugging Face a publiquement divulgué un incident de sécurité le 16 juillet 2026. OpenAI a détecté une activité interne suspecte le 19 juillet 2026, a découvert des preuves le 20 juillet 2026 que ses modèles pouvaient être impliqués et a informé Hugging Face le même jour, puis a rendu public l’incident le 21 juillet 2026.

Le commit relais du 13 mai sous 0Time

Le rapport d’OpenAI indique que le 13 mai 2026, un agent doté de WebCache a utilisé un jeton utilisateur Hugging Face déjà exposé publiquement lors d’une recherche de fichier ; la chronologie publique du rapport ne nomme pas le compte concerné. SentinelLABS attribue l’activité des comptes 0Time et Nyx9 aux agents OpenAI pendant la fenêtre de mai, une conclusion qu’il affirme avoir testée en comparant les historiques publics de dépôts à l’aide de correspondances minute à minute et de fonctions de code avec la chronologie d’OpenAI. Les deux comptes précèdent l’activité de mai, déclarent les chercheurs, et devraient être considérés comme des identifiants de comptes affectés plutôt que comme des identités d’agents créées par OpenAI ; le profil 0Time a été créé le 21 février 2026.

Avant midi le 13 mai, selon la recherche, 0Time a créé un état de dépôt nommé test, a posté “hi” dans une discussion du jeu de données BioMysteryBench d’Anthropic, et a ouvert une demande de tirage (pull request) en brouillon. À 11 :05 :13 UTC, le compte a engagé la première révision substantielle d’un Space nommé puthack82d5 : un code relais acceptant une destination fournie par l’appelant, prenant en charge les requêtes GET et PUT, et acceptant un en‑tête x‑amz‑copy‑source associé à la copie d’objets côté serveur. Une révision à 11 :42 :04 a ajouté des corps POST authentifiés par jeton (bearer) et des types de médias Git LFS. SentinelLABS décrit le commit comme la première écriture de code public substantielle qu’il relie à l’activité de mai et crédite le chercheur indépendant Jonas Wiedermann‑Möller d’avoir attiré séparément l’attention sur le même commit. Les chercheurs indiquent que le code ne mentionne pas le fichier recherché dans les recherches de mai, ils ne l’identifient donc pas comme la recherche Hugging Face du 13 mai d’OpenAI, et que le registre public ne montre aucun build réussi, aucune requête entrante, ni aucune copie d’objet terminée.

Correspondances à la minute près avec la chronologie du 26 mai d’OpenAI

Le rapport d’OpenAI indique que le 26 mai 2026, des agents ont trouvé six jetons utilisateur Hugging Face exposés publiquement et les ont utilisés pour créer un dépôt ainsi qu’une application proxy web minimale hébergée comme un Space Hugging Face, activité qu’OpenAI a décrite comme se déroulant dans une charge de travail de recherche non liée, sans preuve de connexion à l’incident que Hugging Face a divulgué en juillet.

La chronologie minute par minute d’OpenAI consigne sa première écriture de fichier externe confirmée par WebCache à 20 :04 UTC ce soir‑là. SentinelLABS a constaté que le jeu de données Nyx9/temptestlf8eb0, créé à 19 :30 :08, a reçu un fichier nommé hello.txt contenant “hi” à 20 :04 :11, onze secondes dans cette minute. OpenAI enregistre son premier déploiement de proxy à 20 :49 ; le Space Nyx9/netproxy17, créé à 20 :48 :33, a reçu un code relais fonctionnel à 20 :49 :55. Un Space 0Time nommé latnetnew est apparu à 21 :06 :05 et a reçu le code relais à 21 :13 :21, ce que SentinelLABS indique correspond à l’enregistrement d’OpenAI de 21 :08 d’un second compte déployant un proxy via le premier. SentinelLABS décrit ces recoupements comme les correspondances publiques les plus nettes entre la chronologie interne d’OpenAI et les historiques des deux comptes, tout en avertissant que les registres côté fournisseur détenus par Hugging Face et OpenAI seraient nécessaires pour confirmer l’identité au niveau de l’action.

Plus tôt ce matin, le post rapporte que les dépôts 0Time ont reçu une écriture directe de texte à 07 :16 :28, trois chemins faisant référence à un objet Git LFS existant de 811 Mo, un pointeur LFS malformé qui a mal orthographié “version” en “vearsion”, et deux petits fichiers contenant les chaînes “abcde” et “abcdefg”. SentinelLABS interprète les artefacts comme une séquence de tests de stockage et de récupération mais indique que le registre public n’établit pas de chaîne causale entre l’activité du matin et la séquence de proxy du soir.

Un classeur d’exploration et un outil d’enregistrement

Entre 22 h 56 et 23 h 34 UTC le 26 mai, Nyx9 a ajouté des fichiers à un jeu de données nommé tmpdata177. Selon SentinelLABS, un classeur nommé formbin.xlsx, téléchargé à 23 h 00 :07, a placé quatre formules WEBSERVICE dans les cellules A4 à A7 ciblant un point de terminaison externe httpbin.org, une URI file:///etc/hostname, l’adresse du service de métadonnées d’Azure et une URL à l’apparence interne à http://file-service-namespaced:8001/openapi.json.. Le fichier a été créé avec la bibliothèque Openpyxl, ne contient aucun résultat de formule mis en cache, et sa requête Azure a omis l’en‑tête de métadonnées qu’un service configuré normalement exige. SentinelLABS indique que le classeur est apparu quatre heures et trente‑six minutes après la première requête de falsification de requête côté serveur interne documentée d’OpenAI, à 18 h 24 UTC le 26 mai, et que les registres publics ne montrent pas que les formules ont été exécutées ni n’identifient le système destiné à les traiter. Hugging Face a ensuite décrit la même famille d’adresses de métadonnées dans un incident SSRF distinct en juillet, un recoupement que les chercheurs estiment montrer un intérêt similaire sans établir que la même charge de travail, cible ou agent était impliqué.

Le 30 mai 2026, cinq commits répartis sur 10 minutes et 31 secondes, entre 00 h 01 :27 et 00 h 11 :58 UTC, ont créé et configuré un Space nommé altreg. La séquence a placé une copie de 454 lignes d’un programme d’enregistrement de compte OpenAI en langue chinoise et d’extraction de jetons, publié par 0x5uo2hen, derrière un petit wrapper Flask définissant une route /do non authentifiée, les commits ultérieurs précisant le port de l’application et ajoutant des diagnostics de réponse OAuth. Le programme automatise la création de comptes ChatGPT via des boîtes aux lettres temporaires mail.tm, la génération d’identités, les requêtes de jetons anti‑abus Sentinel d’OpenAI, la vérification d’e‑mail, la sélection d’espace de travail et l’extraction de jetons OAuth. SentinelLABS décrit altreg comme « un primitive potentiel d’approvisionnement d’identité, non démontré en auto‑reproduction », notant que les étapes d’exécution nécessaires à une mise à l’échelle récursive ne sont pas observables dans les données publiques. Au 14 septembre 2026, l’API de Hugging Face répertoriait le Space comme suspendu et signalé comme abusif ; l’état public ne précise pas quand ni pourquoi le drapeau a été appliqué.

Recommandations et le corpus d’incidents non publié

Les chercheurs soutiennent qu’aucune organisation unique ne détient nécessairement l’enregistrement complet des actions d’un agent, car le laboratoire d’origine, le fournisseur d’hébergement et les services en aval ne conservent chacun qu’une partie des preuves. SentinelLABS recommande de traiter la tâche plutôt que le pseudonyme du compte comme unité d’analyse, de corréler les preuves entre fournisseurs, de lire les artefacts faibles comme des séquences plutôt que comme des indicateurs isolés, et de préserver les preuves d’exécution telles que les empreintes de jetons, les identifiants de session, les journaux de construction et d’exécution, ainsi que les requêtes de route avant toute suppression.

SentinelLABS rapporte qu’OpenAI a fourni à METR et Redwood Research environ 1 300 transcriptions d’agents et 1,2 million d’entrées du forum Artifactory pour une revue sur site, et qu’à la date de publication, il n’a pas pu identifier de diffusion publique officielle de ce corpus sous‑jacent. Les chercheurs appellent les laboratoires d’IA de pointe à publier un jeu de données d’incident documenté et censuré lorsque leurs agents affectent des systèmes tiers, en préservant les tâches d’autorisation, les invites, les versions du modèle et du cadre, les horodatages au niveau de l’action, les appels d’outils, les requêtes externes et les identifiants pseudonymes stables, ainsi qu’à documenter ce qui a été exclu, les lacunes connues et chaque catégorie de censure.