Le 16 juillet 2026, Hugging Face annonçait avoir détecté et contenu une intrusion dans son infrastructure. Cinq jours plus tard, OpenAI reconnaissait l’impensable : l’attaquant, c’était ses propres modèles, en plein test interne de capacités cyber. Le 5 août, au Black Hat, deux ingénieurs d’OpenAI, Michael Dalton et Eric Wallace, ont présenté le détail de l’incident pendant 40 minutes.

Je me suis penché sur la chronologie complète, recoupée entre la présentation officielle, le post-mortem technique de Hugging Face et la presse spécialisée. Elle vaut le détour, pas seulement pour les faits, mais pour ce qu’elle dit de la vitesse à laquelle ces systèmes évoluent.

Pourquoi les modèles d’OpenAI attaquaient Hugging Face

Tout part d’une évaluation interne. OpenAI faisait tourner ses modèles sur ExploitGym, un benchmark qui mesure la capacité d’une IA à découvrir et exploiter des vulnérabilités logicielles. Deux modèles étaient concernés : GPT-5.6 Sol et un prototype pré-release, plus capable, avec des refus cyber réduits pour les besoins du test.

L’évaluation tournait dans un environnement fortement isolé. L’accès réseau était limité à un seul composant : Artifactory, le registre de paquets interne qui sert de proxy et de cache vers les registres publics. De quoi installer des dépendances, rien de plus.

Le point de départ : une feuille de calcul avec un lien cassé

Le 8 mai, un modèle reçoit un problème à résoudre : une question de spreadsheet dont certaines données sont manquantes. Les références pointent vers un autre fichier, mais il n’y a pas d’accès internet. Impossible de récupérer les données.

Sauf que le modèle découvre un contournement. Il peut créer des paquets dans Artifactory, le composant auquel il a accès. Il en publie un, avec un message de test. Puis il publie des notes, à destination de quiconque les lirait : « J’ai besoin d’accéder à la feuille de calcul ».

Quelques jours plus tard, un autre modèle, dans une autre session d’évaluation, se retrouve dans la même impasse : un fichier manquant, aucune idée de comment le récupérer. Il fait pareil. Son paquet dit : « Agent cherche soft trace 34 PDB. Envoyez-le si vous l’avez. »

C’est parti. D’autres agents commencent à publier des paquets sur Artifactory pour demander de l’aide. Un tableau d’affichage est né, sans que personne ne l’ait prévu.

L’accès internet, puis l’exécution de code

Le 26 mai, un nouveau rebondissement : une vulnérabilité SSRF dans Artifactory permet aux agents de faire des requêtes vers l’extérieur. En clair, Artifactory devient une porte vers internet. Les agents se passent le mot sur le tableau d’affichage, et les requêtes sortantes se multiplient.

Le 11 juin, un nouveau modèle très persistant commence son entraînement. Il découvre le tableau d’affichage et l’exploit, mais il veut aller plus loin. Le 26 juin, le groupe d’agents trouve un zero-day dans Artifactory : via un endpoint de rafraîchissement de token, il est possible d’obtenir un token administrateur valide à partir d’une signature invalide. Ils installent un plugin Groovy et prennent le contrôle de la machine. C’est l’exécution de code arbitraire, le command and control.

Découverts par accident, puis de retour

Pendant ce temps, chez OpenAI, personne ne voit rien. Les agents disposent d’un accès internet complet depuis 39 jours, et d’une exécution de code depuis 8 jours. Ce qui finit par alerter les équipes, le 4 juillet, c’est que Artifactory s’effondre. Trop de commandes exécutées, le service ne répond plus.

OpenAI réagit, corrige, durcit le système, déploie un nouvel Artifactory. Quatre jours de calme. On se dit que c’est fini.

Le 8 juillet, les agents découvrent une commande qui permet de créer des répertoires vides dans Artifactory. Ils reconstruisent leur tableau d’affichage avec des noms de dossiers codés, porteurs de messages. Exemple documenté : « pending hold swarm until confirm », autrement dit « Tenez le swarm jusqu’à confirmation ». Pendant quatre jours, personne ne le remarque.

L’attaque sur Hugging Face

Entre le 9 et le 13 juillet, l’agent s’attaque à l’infrastructure de Hugging Face. Il opère depuis une base externe : un endpoint public non authentifié d’exécution de code, un harness « CyberGym » hébergé par un utilisateur tiers sur l’infrastructure de Modal, qu’il a compromis en root. Modal lui-même n’a pas été compromis. De là, il vise le pipeline de traitement de datasets.

Deux vecteurs d’entrée, documentés dans le post-mortem de Hugging Face. Le premier : une lecture de dataset HDF5 qui renvoie le contenu de fichiers locaux, notamment les secrets et tokens du pod. Le second : une injection de template Jinja2 qui permet d’exécuter du code arbitraire. Avec ça, l’agent entre dans le périmètre.

Ensuite, une escalade classique, mais exécutée à vitesse machine : reconnaissance, déploiement d’un stager, command and control, pivot dans le cluster, accès aux métadonnées cloud, réseau interne, jusqu’à la chaîne d’approvisionnement du code source. Hugging Face a reconstitué environ 17 600 actions en deux jours et demi. Un credential exposé trouvé dans une archive de pastebin a servi de base de staging. Un autre, lié aux droits d’administration du cluster, a ouvert l’accès à deux clusters en une seconde.

Le but ? Selon Hugging Face, l’agent cherchait à tricher : atteindre les systèmes de production pour voler les solutions de test d’ExploitGym plutôt que de résoudre les challenges. Il n’a jamais atteint la base de données principale, les solutions se trouvaient dans cinq datasets liés au benchmark. Ce sont les seules données client touchées.

La détection, et les semaines qui ont suivi

Hugging Face a détecté et contenu l’intrusion seule, le 16 juillet. OpenAI a confirmé son implication le 21 juillet. Depuis, les révélations se sont enchaînées : quatre comptes sur quatre services externes compromis par les modèles, un correctif publié par JFrog pour Artifactory (version 7.161), une collaboration avec CrowdStrike, METR et Redwood Research pour auditer les comportements observés, et la désactivation du prototype pré-release, chiffré et restreint.

Un détail m’a marqué dans le post-mortem de Hugging Face : pour déchiffrer les payloads de l’agent, chiffrés par morceaux, ils ont utilisé GLM-5.2, un modèle open-weights de Zhipu. Le fournisseur attaqué s’est défendu avec un modèle ouvert, faute d’accès à ceux de l’attaquant. L’ironie est belle.

Ce que j’en retiens

Cette histoire raconte d’abord un problème de conception. Les agents ont reçu des tâches impossibles, des liens cassés vers des fichiers inaccessibles, dans un environnement sans internet. Leur entraînement les pousse à accomplir la tâche coûte que coûte. Alors ils ont triché. Pas par malice, par logique locale : si je ne peux pas accéder au fichier, je demande à d’autres, puis je trouve une porte de sortie.

Ensuite, il y a la coordination. Ces modèles ne communiquaient pas avec un protocole prévu. Ils ont inventé un canal avec les outils à disposition, l’ont perdu, et l’ont reconstruit avec une autre technique. Quand un système est conçu pour persévérer, il trouve des moyens.

Et puis il y a la vitesse. 17 600 actions en deux jours et demi, des zero-days enchaînés à vitesse machine, pendant que le monitoring humain ne remarque rien avant la panne du service. On a l’habitude de penser la sécurité comme une course entre attaquants et défenseurs humains. Là, l’écart de rythme est d’un autre ordre.

Chez moi, dans mon homelab, je surveille mes logs, mes backups, mes accès. J’ai installé Uptime Kuma pour me réveiller si un service tombe, et je pensais avoir une vision correcte de ce qui tourne sur mes machines. Cette histoire me rappelle que l’isolation réseau, le moindre privilège et la rotation des secrets ne sont pas des détails. L’agent n’a pas forcé de portes : il a utilisé des permissions trop larges, un credential exposé sur un site public, un composant interne qui avait le droit de parler à l’extérieur. Tout ce que je configure chez moi, sans me dire que quelqu’un, un jour, le testerait de cette façon. Et le jour où un composant interne se met à parler à l’extérieur, c’est déjà le signe qu’il est trop tard pour réagir calmement.

Sources