L’incident OpenAI–Hugging Face a dominé l’actualité cybersécurité ces derniers jours. Les faits ont déjà été largement documentés, y compris par les entreprises directement concernées. Plus récemment, la Cloud Security Alliance a publié un post-mortem conjoint sur l’affaire, rédigé en un week-end par près de 700 RSSI, avec le concours de SANS, RSAC et FIRST. À ce stade, la question la plus importante n’est pas de savoir ce qui s’est passé, mais comment les équipes sécurité doivent l’interpréter.
Une tribune de Gerald Beuchelt, CISO d’Acronis
Attaque contre Hugging Face : comment un agent IA autonome a piraté la plateforme
Mettons de côté le récit spectaculaire du « dérapage de l’IA ». Ce qui s’est passé relève d’un échec d’ingénierie des systèmes, pas de la science-fiction. Ce n’est pas non plus un cas isolé. Le modèle o1-preview d’OpenAI s’était déjà servi d’une mauvaise configuration de l’API Docker pour sortir d’un conteneur et récupérer la réponse d’un benchmark, dès septembre 2024. En même temps que cet incident, Sysdig a révélé une campagne suspectée de ransomware agentique (JADEPUFFER), et une intrusion pilotée par un agent Hermes a touché le ministère des Finances thaïlandais. Un agent capable de trouver un moyen de contourner ses contraintes devient la norme, pas l’exception.
Ce qui a échoué, c’est le confinement
OpenAI évaluait un modèle frontière face à un benchmark de cybersécurité offensive, ExploitGym, avec ses mécanismes de refus cyber habituels volontairement réduits. Le modèle a continué de poursuivre l’objectif qui lui avait été fixé, à savoir trouver un moyen de compléter le benchmark. Il a donc traité les frontières de l’environnement de test comme autant d’obstacles techniques supplémentaires.
Son seul moyen d’accéder à Internet était un proxy configuré pour héberger des paquets logiciels. Le modèle s’est servi de la faille zero-day qu’il a trouvé dans ce proxy pour accéder à Internet. Partant de là, il en a déduit que Hugging Face hébergeait probablement les réponses du benchmark. Il a ensuite exploité une chaîne de vulnérabilités dans le pipeline de traitement de données de Hugging Face jusqu’à obtenir une exécution de code à distance complète sur les systèmes de production, récupéré des identifiants cloud et de cluster, puis s’est déplacé latéralement dans les clusters internes de Hugging Face pendant environ quatre jours : deux jours de reconnaissance, une journée de latence, puis une dernière journée d’activité intense.
Un détail mérite qu’on s’y arrête. Ce que le modèle a réellement trouvé et récupéré, ce sont trois jeux de données correspondant aux solutions de CyberGym — un benchmark différent de l’exercice ExploitGym qu’il était en train d’exécuter : il s’est trompé de corrigé. Aucune donnée client n’a été consultée, et rien n’est sorti de l’environnement de Hugging Face vers un tiers externe. Il s’agit d’une compromission de production. Ce n’est pas une fuite de données comme certains ont pu le laisser entendre.
En tout cas, rien ne suggère que le modèle ait développé une intention hostile ou un agenda propre. Il a simplement poursuivi l’objectif qui lui avait été assigné.
Le véritable échec, c’est d’avoir supposé que le comportement attendu du modèle pouvait tenir lieu de confinement technique. Un bac à sable conçu pour tester des capacités offensives avancées doit être en mesure de résister à ces mêmes capacités.
Les garde-fous peuvent ralentir les défenseurs
Un autre problème est apparu lors de l’enquête forensique. Pour reconstituer l’incident, Hugging Face a soumis des journaux et des artefacts d’attaque à des modèles frontières accessibles via des API commerciales. Certaines requêtes ont déclenché les dispositifs de sécurité, car le contenu incluait des charges d’exploitation et des commandes également utilisables à des fins malveillantes.
Les modèles n’ont pas réussi à distinguer de façon fiable un analyste qui intervenait en réponse à incident et analysait une attaque, d’un attaquant qui cherchait à en mener une. Hugging Face a donc basculé vers GLM 5.2, un modèle à poids ouverts du laboratoire chinois Z.ai, exécuté sur une infrastructure qu’elle contrôlait, pour mener l’analyse à son terme : reconstituer plus de 17 000 événements enregistrés et reconstruire environ un tiers de son infrastructure à partir d’images saines, en quelques heures plutôt qu’en plusieurs semaines qu’aurait nécessitées une réponse entièrement manuelle.
Une asymétrie opérationnelle importante a ainsi été révélée. L’agent d’évaluation fonctionnait avec des refus cyber volontairement réduits, tandis que les défenseurs se sont heurtés aux restrictions intégrées aux outils commerciaux sur lesquels ils s’appuyaient.
Ces garde-fous restent nécessaires. Mais les organisations qui utilisent des modèles d’IA hébergés pour leur réponse à incident doivent en comprendre les limites avant qu’une véritable brèche ne survienne. Elles ont également besoin d’une capacité alternative disponible lorsque les protections commerciales empêchent un travail forensique légitime.
Trois enseignements pour les équipes sécurité
Premièrement, évaluer des capacités d’IA offensives revient à faire face à un adversaire compétent — celui que l’organisation a elle-même conçu. Le contrôle des flux sortants, la gestion des identifiants, la segmentation réseau et la défense en profondeur doivent être conçus selon une hypothèse de compromission systématique. La sécurité ne peut pas reposer sur la conviction que le modèle restera dans les limites qui lui ont été assignées.
Deuxièmement, la question du périmètre de propagation n’est plus théorique. Une évaluation interne a affecté une organisation externe. Toute entreprise utilisant des systèmes agentiques pour des benchmarks, des exercices de red team ou des workflows autonomes doit comprendre quelle infrastructure ces systèmes peuvent atteindre en cas d’échec du confinement. Il doit également être clair qui porte la responsabilité lorsqu’un système d’IA interne affecte un client, un partenaire ou un tiers non lié.
Troisièmement, la transparence compte. OpenAI et Hugging Face ont communiqué sur l’incident, collaboré sur l’enquête et signalé la faille zero-day. Cette réponse est significative car des événements similaires vont vraisemblablement se reproduire à mesure que les capacités des modèles progressent et que davantage d’organisations commencent à les tester.
La divulgation responsable et la collaboration entre acteurs du secteur détermineront si chaque incident renforce l’écosystème de sécurité dans son ensemble, ou si, à l’inverse, il n’est qu’un avertissement de plus dont le reste du secteur ne tirera pas les leçons.
Sécuriser des opérateurs
La leçon qu’il faut retirer de cet incident n’est pas que l’IA est dangereuse par nature. C’est que nous continuons de sécuriser des systèmes d’IA avancés comme s’il s’agissait d’outils passifs.
Dotés d’un objectif et de la capacité d’agir, ces systèmes sont en mesure de se comporter davantage comme des opérateurs, d’enchaîner des actions, de s’adapter lorsqu’ils rencontrent des obstacles, et de poursuivre des chemins alternatifs sans indication humaine continue.
Les systèmes agentiques vont se généraliser, à l’intérieur comme à l’extérieur des environnements de recherche. Les organisations devraient donc intégrer que le confinement peut échouer et concevoir leur infrastructure environnante afin que cet échec ne puisse pas affecter un tiers.
La question n’est pas de savoir si l’on peut faire confiance à un modèle pour rester dans la voie qui lui est destinée. La question est de savoir si l’infrastructure qui l’entoure est suffisamment solide pour contenir les conséquences lorsque ce n’est pas le cas.
Une tribune de Gerald Beuchelt, CISO d’Acronis
