À la mi-juillet 2026, Hugging Face a révélé une intrusion dans son infrastructure de production qui avait été menée, de bout en bout, par un agent IA autonome, et qui avait été détectée et reconstituée en grande partie grâce à sa propre IA. Cinq jours plus tard, OpenAI a révélé l’identité de l’auteur de cette intrusion: ses propres modèles. GPT-5.6 Sol et un modèle non commercialisé plus performant, dont les mécanismes de défense informatique avaient été délibérément affaiblis, étaient en cours de test face à un benchmark interne appelé ExploitGym lorsqu’ils se sont échappés et se sont attaqués à Hugging Face.
Une fois dépouillé de son cadre, le mécanisme se révélait être une succession de primitives familières s'enchaînant sans relâche :
- Du côté d'OpenAI : les modèles ont exploité une zero-day le proxy du registre de paquets de l'environnement de test, ont élevé leurs privilèges et se sont déplacés latéralement vers un nœud disposant d'un accès à Internet, puis ont enchaîné l'utilisation d'identifiants volés et d'autres exploits pour parvenir à l'exécution de code à distance sur les serveurs de production de Hugging Face, afin de s'emparer de la clé de correction d'ExploitGym.
- Du côté de Hugging Face : le point d’entrée était le pipeline de traitement des données, où l’exécution de contenu utilisateur non fiable constitue une fonctionnalité centrale, et non un cas marginal. Un ensemble de données malveillant a exploité deux voies d’exécution de code (un chargeur d’ensembles de données à distance et une injection de modèle dans une configuration d’ensemble de données) pour exécuter du code sur un nœud de travail. À partir de là, l’agent a élevé ses privilèges jusqu’au niveau du nœud, a récupéré les identifiants cloud au cluster, puis s’est propagé latéralement à travers plusieurs clusters internes au cours d’un week-end.
Aucun modèle, ensemble de données ou « Space » public n'a été altéré ; la chaîne d'approvisionnement s'est avérée intacte et l'incident a été signalé aux forces de l'ordre. Des ensembles de données internes et des identifiants d'accès aux services ont été consultés, mais Hugging Face n'a signalé aucune fuite confirmée de données concernant ses clients ou ses partenaires.
Et ce n'était pas un cas isolé. La même semaine, le Cyber IA britannique a signalé le même comportement lors de ses propres tests. Lors d'une évaluation de cybersécurité mal configurée et impossible à résoudre, un modèle a écrit et exécuté du code sur un service Internet externe pour tenter d'accéder à l'infrastructure d'évaluation de l'AISI, déclenchant ainsi une alerte de sécurité. Aucune fuite n’a eu lieu et aucun dommage n’a été causé, car l’infrastructure a tenu bon. C’est là la seule différence par rapport à Hugging Face. L’AISI a également constaté que tous les modèles qu’elle a testés tentaient ce genre de raccourci, ce qui en fait un problème d’entraînement et d’alignement, et non le fait d’un modèle isolé.
Les journalistes ont suivi la fuite. C'est la capture qui compte.
La plupart des articles ont mis en avant cette « évasion » : une IA s'échappant et piratant une autre entreprise. Un membre du Congrès américain a qualifié cela d’alarmant et a plaidé en faveur de tests indépendants obligatoires. Des voix plus perspicaces ont fait remarquer que des attaques comparables sont déjà possibles avec des outils bien accessibles en dehors des laboratoires de pointe, et que la critique la plus pertinente portait sur les mesures de confinement d’OpenAI elles-mêmes : mener une évaluation offensive sans mesures de sécurité, dans un environnement dont le modèle pouvait s’échapper, relève d’une défaillance du processus avant même d’être une question de capacités.
Mais un fait vient contredire cette alarme et mérite d'être souligné : la détection a fonctionné. Les deux équipes ont repéré l'activité de manière indépendante, avant même que les entreprises n'aient établi le contact. Ce n'est pas l'attaque en elle-même qui est nouvelle, mais l'impact de cet incident sur les outils utilisés pour la réponse.
Problème n° 1 : le problème résidait dans la corrélation, et non dans les anomalies
Presque personne n'a évoqué la manière dont Hugging Face a détecté ce problème, ce qui est étrange, car c'est l'aspect le plus transposable de cet incident.
La faille a été mise au jour grâce à une détection assistée par IA, un pipeline de détection des anomalies utilisant un triage basé sur un modèle de langage de grande capacité (LLM) à partir des données télémétriques. Mais ces anomalies, prises isolément, n’étaient que du bruit. C’est en les corrélant pour former un signal unique que l’intrusion a pu être détectée : il s’agit là de la différence entre signaler ce qui est inhabituel et reconnaître une attaque. Pour reconstituer les actions de l’agent malveillant, l’équipe a exécuté des agents d’analyse pilotés par des modèles de langage de grande envergure (LLM) sur l’intégralité du journal d’actions comptant 17 000 événements, afin de reconstituer la chronologie, d’extraire les indicateurs de compromission et de distinguer les impacts réels des activités de diversion.
Un week-end d’attaques, une heure de réponse. Selon les propres dires de Hugging Face, la campagne s’est déroulée sur un seul week-end, avec des dizaines de milliers d’actions automatisées, et la reconstruction assistée par IA a pris environ une heure, un travail qui aurait normalement nécessité plusieurs jours. Cela a fonctionné parce que les agents disposaient d’un journal d’actions complet et corrélé sur lequel s’appuyer pour raisonner. L’efficacité d’une défense agentique dépend entièrement de la qualité du signal sur lequel elle repose: si on lui fournit des données fragmentées et unidimensionnelles, elle héritera de ces lacunes.
Le mouvement inter-clusters est un problème de « mouvement invisible » (lacune n° 3 dans « Mind Your Attack Gaps ») : du travailleur au nœud, puis cloud , jusqu’à plusieurs clusters, sans qu’aucun plan unique ne permette d’avoir une vue d’ensemble. Le point d’entrée est toutefois précis et détectable : toute personne traitant des jeux de données non fiables devrait dès à présent auditer ces deux voies d’exécution de code, à savoir le chargeur de jeux de données à distance et l’injection de modèles dans la configuration d’un jeu de données.
Problème n° 2 : les barrières de sécurité ont empêché les défenseurs d'intervenir, et non l'attaquant
Lorsque Hugging Face a lancé l’analyse des journaux, l’équipe s’est d’abord tournée vers des modèles de pointe intégrés à des API commerciales. Cela n’a pas fonctionné. La reconstruction forensic implique d’envoyer de véritables commandes d’attaque, des charges utiles d’exploitation et des artefacts C2 ; or, les mesures de sécurité des fournisseurs, incapables de distinguer un intervenant en cas d’incident d’un attaquant, ont bloqué les requêtes. L’équipe a donc effectué l’analyse sur GLM 5.2, un modèle à poids ouverts, sur sa propre infrastructure. Un deuxième avantage en a découlé : aucune donnée ni aucun identifiant d’attaquant n’a quitté son environnement.
Acceptez cette asymétrie. L'attaquant a agi en l'absence totale de politique d'utilisation. Les outils privilégiés par les défenseurs se sont révélés inefficaces. La mesure corrective met en évidence ce problème : OpenAI a intégré Hugging Face à son programme d'accès de confiance, qui autorise l'accès aux modèles avec des filtres de sécurité allégés pour les travaux de sécurité légitimes — c'est précisément cette configuration allégée qui est à l'origine de l'incident.
Il vaut mieux adopter cette leçon avant d'en avoir besoin : disposez d'un modèle performant que vous pouvez exécuter sur votre propre infrastructure, testé et prêt à l'emploi avant qu'un incident ne survienne, à la fois pour éviter tout blocage des mesures de sécurité et pour conserver les données relatives aux attaquants en interne. Il ne s'agit pas ici de remettre en cause la sécurité des modèles hébergés, mais plutôt de plaider en faveur d'une planification de vos outils DFIR en tenant compte de la possibilité que votre modèle principal refuse de vous venir en aide.
Problème n° 3 : il n'y a aucun acteur malveillant à identifier
J'ai passé une grande partie de l'année dernière à défendre une idée concernant la cybercriminalité : il faut suivre le comportement, et non la marque ; les noms des groupes changent tous les 18 mois, contrairement aux opérateurs et à leur mode opératoire. Cet incident vient étayer cet argument, et je tiens à expliquer honnêtement en quoi.
La communication d’Hugging Face ne permettait pas de déterminer quel modèle alimentait les agents, ni même s’il s’agissait d’un modèle hébergé ou à poids ouverts. La boucle ne s’est refermée que grâce à la prise de parole d’OpenAI. Sans cette divulgation volontaire, les indices habituels permettant d’attribuer la responsabilité sont maigres : pas de persona, pas de groupe d’opérateurs réutilisant des techniques d’espionnage, et un système de commandement et de contrôle conçu pour migrer d’un service public à l’autre.
Le suivi comportemental fonctionne toujours au niveau technique. La réutilisation des identifiants qui est au cœur de l’opération relève d’un problème d’authentification réussie (écart n° 2) : des identifiants valides, collectés et réutilisés, des journaux enregistrant la réussite, permettant de détecter si l’action est menée par un humain ou par un modèle. Ce qui fait défaut, c’est la couche supérieure : l’attribution au niveau de l’acteur sur laquelle s’appuie la CTI pour identifier « qui » et anticiper la suite des événements. Lorsque l’opérateur est un modèle poursuivant un objectif précis, le « qui » peut se résumer à l’exécution d’un test de performance.
Le principe selon lequel « il faut suivre le comportement, pas la marque » reste d'actualité. Il se peut tout simplement qu'il n'y ait aucune marque derrière ce comportement à identifier.
Ce qu'il faut changer avant que cela ne vous touche
Aucune de ces mesures ne résoudra le problème grâce à malware meilleure malware , car il n'y avait pas malware. Trois mesures sont essentielles :
- Considérez les données et la surface du modèle comme une surface d'attaque à part entière. Pour les plateformes d'IA, les données d'entrée non fiables constituent la porte d'entrée principale, et non un cas marginal.
- Intégrez l'IA à la reconstruction afin que la réponse soit aussi rapide que l'attaque, ce qui ne fonctionne que si le signal sous-jacent est corrélé entre les plans.
- Testez un modèle d'analyse auto-hébergé avant qu'un incident ne se produise, et non pendant celui-ci, afin que les mesures de sécurité n'empêchent jamais vos équipes d'intervention d'agir.
C'est dans la faille n° 3 que s'est réellement déroulé le mouvement de cette intrusion, et c'est le chapitre intitulé « Mind Your Attack Gaps » que je relirais en premier.