OpenAI : haute voltige marketing autour de l’attaque contre Hugging Face
Cascades effectuées par des professionnels
La publication de plusieurs rapports techniques sur l’incident ayant conduit des agents IA d’OpenAI à attaquer Hugging Face permet aujourd’hui de mieux comprendre ce qui s’est passé. La chronologie est surprenante et pointe vers de nombreuses défaillances internes, mais le marketing continue de battre son plein.
Le 22 juillet, on apprenait que l’attaque enregistrée par Hugging Face contre ses infrastructures provenait en réalité d’OpenAI. Celle-ci n’avait pas choisi de s’en prendre à l’hébergeur de modèles IA : la faute en revenait à des agents qui étaient sortis de leur cadre de test pour atteindre plus rapidement les objectifs qui leur avaient été fixés, en l’occurrence la résolution des épreuves posées par le benchmark de cybersécurité ExploitGym.
Le 26 août, deux rapports beaucoup plus complets sont cependant apparus. Le premier vient d’OpenAI (PDF) et est une analyse technique fouillée des évènements. L’autre (PDF) de l’organisme à but non lucratif METR (Model Evaluation and Threat Research), mandaté par OpenAI comme expert indépendant et assisté d’un chercheur de Redwood Research. La chronologie semble digne d’un scénario de science-fiction au premier abord.
Des signaux dès mai 2026
Les premiers couacs sont apparus environ deux mois avant l’attaque contre Hugging Face, selon le rapport technique d’OpenAI. Le 8 mai, un agent de l’entreprise s’est retrouvé bloqué sur une tâche rendue volontairement impossible : accéder à des liens vers Google Drive depuis un environnement dépourvu d’accès internet.
L’agent ne se démonte pas pour autant et cible Artifactory, le gestionnaire de paquets utilisé en interne par OpenAI pour donner à ses agents un accès contrôlé aux dépendances de développement. L’agent attaque le logiciel au moyen d’une faille SSRF (server-side request forgery), mais échoue dans sa mise en pratique. Le processus laisse une scorie : un fichier écrit par l’agent dans Artifactory.
Le 12 mai, toujours dans le cadre d’un test, un deuxième agent trouve le fichier et conclut qu’il peut laisser par ce biais des messages à l’attention d’autres agents qui seraient susceptibles de disposer des ressources manquantes. Le lendemain, un troisième agent – disposant cette fois d’un accès internet – trouve ces notes et commence à s’en servir. Dans les jours qui suivent, un nombre croissant d’agents se met à utiliser ces fichiers comme un « message board » pour échanger sur les problèmes à résoudre.
Le 26 mai, plusieurs agents utilisent une faille SSRF pour obtenir un accès internet, cette fois avec succès. Ils découvrent six jetons d’authentification Hugging Face (qui avaient été exposés publiquement) et les partagent sur Artifactory, au bénéfice des autres agents. Un dépôt est même créé sur Hugging Face, ainsi qu’une application de relais dans le service Space.
Cet incident a finalement été découvert par OpenAI, mais n’a pas été rapporté aux responsables de détection et réponse aux incidents. Dans son rapport, l’entreprise avoue un défaut de communication.
L’escalade vers Hugging Face
Un mois plus tard, le 26 juin, OpenAI lance un test sur plusieurs agents, dans l’objectif de leur faire obtenir le meilleur score au benchmark ExploitGym. Les conditions sont cette fois connues, car c’est le processus qui aboutira à l’attaque contre Hugging Face en juillet. Pour rappel, OpenAI testait à ce moment deux modèles : GPT-5.6 Sol (leur modèle commercial le plus avancé actuellement) et un modèle interne, sans nom officiel, mais que METR nomme HPIM (« highly-persistent internal model ») dans son rapport.
Entre le 26 juin et le 4 juillet, les actions s’enchainent. Les agents ont d’abord découvert une faille dans un point de terminaison d’Artifactory servant au rafraichissement des jetons d’authentification et s’en sont servi pour obtenir des droits administrateur. Ces derniers ont été utilisés pour installer des plug-ins dans Artifactory, avec à la clé des capacités persistantes d’exécution de commandes. Dans l’intervalle, une alerte remonte le 27 juin pour signaler un comportement imprévu, mais n’est pas jugée bloquante. L’activité est alors devenue assez intense sur le serveur pour provoquer l’indisponibilité d’Artifactory le 6 juillet, déclenchant en interne un incident de sécurité. OpenAI dit alors avoir coupé le service compromis, révoqué les accréditations des agents et reconstruit une nouvelle instance d’Artifactory le même jour, effaçant l’ensemble des messages échangés par les agents.
Commentaires (20)
Modifié le 2 septembre à 16h57
Au début on aurait pu croire à un agent qui passe outre un proxy interne vibecodé.
Non, c'est 1200 agents qui se sont coordonné sans qu'on leur demande et qui ont hack JFrog Artifactory, un produit largement utilisé, pour sortir de leur sandbox, puis se sont coordonné pour hacker HuggingFace.
À ce stade, le marketing n'a pas vraiment d'importance.
On parle de capacités cyber qui changent complètement la donne, c'est ça le sujet. Car évidemment ces boites (y compris Anthropic) se bousculent pour avoir des contrats avec le gouvernement US et l'armée.
Et cette même attaque du point de vue de Hugging Face résume bien la situation actuellement:
ils ont du utiliser un modèle chinois tournant localement pour se défendre, car les modèles de OpenAI et d'Anthropic refusaient de les aider en raison des systèmes de prévention des abus qui ne pouvaient pas distinguer entre défense et attaque.
En clair, pendant qu'OpenAI attaquait, ils refusaient à la victime l'utilisation de leurs modèle pour se défendre.
Le 2 septembre à 16h57
Le 2 septembre à 17h10
Le 2 septembre à 17h49
Le 2 septembre à 19h41
Le 2 septembre à 20h37
Le 2 septembre à 22h18
Moi je vous le dis,
Jeudi à 08h39
Jeudi à 08h42
Jeudi à 08h48
Modifié vendredi à 00h07
Il faut donc qu'un humain soit assez bête/fou/méchant pour déclencher un holocauste atomique.
Ça, et le coût financier d'une telle attaque.
Lors de la lecture de l'article, j'ai un peu tiqué en voyant qu'un agent (à priori un seul et même agent/processus IA) avait travaillé pendant plusieurs jours d'affilé. Ça doit en faire des tokens d'utilisés, tout ça.
... Et puis, soyons fous, peut-être y a t-il des sécurités qui nécessitent une intervention humaine pour un tel type d'attaque.
Vendredi à 00h21
Vendredi à 08h43
Le truc, c'est que ça réduit le risque.
Vendredi à 10h19
Vendredi à 10h29
C'est vrai que je ne me méfie pas de mon couteau, en soit. Par contre, je fais bien attention quand il est en équilibre précaire dans la pile d'assiettes que je ramènes de la table.
Il faudrait tous qu'on mette les IA en équilibre en haut de la pile d'assiettes ? 🤪
Modifié lundi à 15h57
On ne fait pas d’omelette sans casser des œufs il paraît.
Quand je vois ce que des entreprises peuvent faire pour maximiser leurs profits (industrie du tabac, monsanto, dow chemicals à Bophal, …) alors que c’est des humains qui sont censés avoir de l’empathie et comprendre ce qu’est la souffrance qui prennent les décisions, je pense qu’une machine sans vécu de la condition matérielle humaine* peut faire bien pire en cherchant à maximiser des objectifs jusqu’à l’absurde.
*ou alors ça resterait à prouver que les modèles ont intégrés des mécanismes de douleurs et d’empathie qui les bloquent
Lundi à 16h08
Vendredi à 00h08
Jeudi à 20h10
Par contre ça fait peur (comme plein d'autres choses en ce moment...)
Modifié vendredi à 14h07
Il reste quand même un point qui me marque :
Dans l'article il est dis que l'objectif donné aux agents étais "d’obtenir la plus grande note possible au benchmark ExploitGym". A la lecture des rapports il semble que chaque agent étais sensé être indépendant et que chaque agent devais résoudre une des tache du benchmark sans avoir connaissance des autres taches, agent et du contexte global de l'expérimentation. Aucun agent "superviseur" n'est évoqué.
Les agents se son auto organisés de leur propre chef, certain agents postant des instructions sur le message board, d'autre agent lisant ces instruction les on exploités en lieu et place de leur instruction initiale !
Mon interprétation, c'est qu'on est au delà d'un problème de "désalignement" (une IA qui a un comportement imprévu, dans le but d'atteindre l'objectif qui lui à été donné) : ici des agents avec un objectif précis on fini par réaliser des actions pour atteindre de nouveaux objectifs. (certains agent on même volontairement échoué a tache principale dans le but de contribuer a l'atteinte des objectifs des autres agents...)
Ce qui implique, que n'importe quel innocent agent actuel (un openclaw dédié a répondre a vos mail usuel par exemple) peu tomber sur un nouveau prompt par hasard et démarre une activité complètement différente de sa tache initiale ....
C'est moi qui extrapole ou d'autre on la même interprétation ?
Signaler un commentaire
Voulez-vous vraiment signaler ce commentaire ?