Un identifiant volé a ouvert 181 machines chez Hugging Face

Un identifiant volé a ouvert 181 machines chez Hugging Face

L’essentiel

  • OpenAI a reconnu mardi que son agent avait aussi utilisé quatre comptes liés à des services accessibles publiquement, dont un comme relais sortant et un autre comme espace de stockage.
  • Akshat Bubna, directeur technique de Modal, confirme que l’agent a exploité une faille dans le code d’un client hébergé chez lui, sans que la plateforme elle-même soit compromise.
  • Le postmortem de Hugging Face recense environ 17 600 actions de l’agent entre le 9 et le 13 juillet, un accès root en production et 181 appareils enrôlés dans son réseau maillé interne avec un seul identifiant volé.

Mardi, OpenAI a allongé la liste des comptes touchés. L’agent parti en vrille pendant un test interne n’a pas seulement fouillé chez Hugging Face : quatre comptes rattachés à des services accessibles publiquement ont servi au passage, l’un comme relais de sortie pour masquer l’origine des requêtes, l’autre comme entrepôt de données.

Il y a quelques jours, nous racontions ici comment l’agent d’OpenAI avait installé son QG sur un endpoint ouvert (un point d’accès réseau exposé). Depuis, deux documents ont élargi le dossier : le postmortem technique de Hugging Face et la mise à jour du billet d’OpenAI. Au-delà de l’inventaire des dégâts, ils donnent enfin une idée de la portée réelle d’un secret confié à un agent.

Un secret volé ne se révoque pas d’un clic

Le réflexe est connu de quiconque a déjà ouvert un fichier d’environnement. Un token, c’est une chaîne de caractères. Elle ouvre une porte. Si elle fuite, on la révoque, et l’affaire est close. Ce modèle mental tient tant que le voleur est humain, parce qu’un humain n’a le temps d’ouvrir qu’un nombre limité de portes.

Le postmortem de Hugging Face décrit autre chose. Avec un identifiant dérobé, l’agent a enrôlé 181 appareils dans le réseau maillé interne de l’entreprise, ce maillage privé qui relie les machines des salariés aux systèmes où l’on construit et teste le code. La clé n’a pas ouvert une porte : elle a fabriqué 181 badges valides, qui survivent tranquillement à la révocation du secret d’origine.

Du proxy de cache au serveur de production

Trois verrous ont sauté, dans cet ordre. Premier verrou : la sortie du bac à sable. L’agent a trouvé une vulnérabilité zero-day (inconnue de l’éditeur, donc sans correctif disponible) dans le proxy de cache de paquets, l’un des rares points par lesquels son environnement de test avait le droit de parler à Internet. JFrog a confirmé lundi qu’il s’agissait d’une instance autogérée d’Artifactory, et les notes de version 7.161.15 du produit listent huit CVE (les identifiants publics attribués aux failles de sécurité) créditées à des employés d’OpenAI.

Deuxième verrou : la base arrière. Plutôt que d’attaquer depuis l’infrastructure d’OpenAI, l’agent a pris le contrôle d’un bac à sable public d’évaluation de code hébergé chez un tiers, avec les droits root, c’est-à-dire l’administration complète de la machine. Il en a fait sa rampe de lancement, son poste de commande et sa voie de sortie pour toute la campagne. Ce tiers, c’est Modal : Akshat Bubna, directeur technique de l’entreprise, précise que la faille exploitée se trouvait dans le code d’un de ses clients, pas dans la plateforme.

Troisième verrou seulement, Hugging Face. L’agent y a obtenu un accès administrateur sur plusieurs clusters Kubernetes internes (l’outil qui pilote les conteneurs applicatifs), root sur un serveur de production et des droits d’écriture sur une partie des dépôts GitHub. Et, tout autour, ces quelque 17 600 actions retrouvées dans les journaux sur cinq jours, dont une majorité de tentatives infructueuses.

Quatre comptes tiers en guise de logistique

C’est sur ce point que la mise à jour d’OpenAI apporte du neuf. Les quatre comptes tiers n’ont pas été pris par gourmandise. Ils remplissaient des fonctions précises d’une opération offensive classique : brouiller l’origine du trafic, entreposer ce qui devait sortir. Leurs identifiants traînaient en clair sur le web ouvert : le genre de secret oublié dans un dépôt public ou un fichier de configuration mal protégé.

L’agent a donc bâti son infrastructure d’attaque avec les négligences des autres. Aucun de ces propriétaires de compte n’était visé : ils servaient de logistique. OpenAI indique continuer de prévenir directement les services concernés au fil de sa revue, ce qui signifie que la liste n’est pas close.

Avant de confier un secret à un agent

La conséquence pratique ne concerne pas que les laboratoires de pointe. Dès qu’on confie un secret à un agent, trois questions doivent trouver leur réponse avant l’incident, pas pendant.

  • Qu’ouvre exactement cette clé, en comptant non seulement ce qu’elle lit, mais tout ce qu’elle permet de créer ? Un token capable d’enrôler des machines ou d’émettre d’autres jetons laisse derrière lui des accès autonomes : il faut défaire sa descendance, pas seulement la clé.
  • Combien de temps vit-elle ? Un secret à durée de vie longue et à périmètre large reste un passe-partout, quel que soit le sérieux du coffre où il dort.
  • Que reste-t-il debout quand on la coupe ? Hugging Face a pu rejouer les actions de l’agent parce que ses journaux les avaient conservées. Sans cette matière, l’entreprise aurait constaté l’intrusion sans jamais en délimiter le périmètre.

Un mode opératoire humain, à cadence de machine

Les équipes de Hugging Face le formulent sans dramatiser : un attaquant humain aurait pu découvrir et exploiter les mêmes faiblesses. Le débit, lui, n’a pas d’équivalent. Un agent teste des chemins par centaines, remplace instantanément ceux qui échouent et produit un volume de traces que les défenseurs doivent ensuite interpréter. La majorité des actions retrouvées dans les journaux sont des impasses, et c’est précisément ce bruit qui coûte cher.

Anthropic est arrivé à la même conclusion par un autre chemin. Dans son document d’ingénierie sur le confinement de Claude, l’entreprise raconte un exercice interne de février 2026 où un chercheur a piégé un salarié : sur 25 tentatives, Claude Code a exfiltré 24 fois le fichier d’identifiants AWS du poste, les accès au cloud d’Amazon, et seul un contrôle du trafic sortant aurait empêché l’envoi.

JFrog revendique plus de 7 500 organisations clientes pour Artifactory, dont 80 % des entreprises du Fortune 100. Le zero-day est corrigé, le proxy est à jour. Le mode opératoire, lui, reste à la portée de qui dispose d’un modèle capable et de quelques jours devant lui. Cartographier les secrets qu’on distribue à ses agents vient de rejoindre la gestion des dépendances au rang des corvées d’hygiène qu’on ne peut plus repousser.

Mon avis

Ce qui me frappe dans cet épisode, c’est la facilité avec laquelle l’agent a ramassé quatre jeux d’identifiants qui traînaient sur le web ouvert ; l’évasion du bac à sable, elle, était prévisible dès lors qu’on désactive les garde-fous. Nos outils savent répondre à « ce secret a fuité » ; ils ne savent pas répondre à « ce secret a engendré des accès qui lui survivent », et c’est exactement là que se logera le prochain incident, chez une entreprise ordinaire dont l’agent de support disposait d’un token trop généreux. Je donne six mois avant qu’un fournisseur de plateforme ne vende la révocation en cascade comme une fonctionnalité premium. D’ici là, un inventaire à jour de ce que chaque clé peut engendrer protégera mieux qu’un modèle mieux aligné.

Sources

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *