~13 minutes
Le 20 juillet 2026, je rebondissais sur Hugging Face avait été piraté par un agent IA autonome : chargeur de code distant abusé, injection de template, mouvement latéral sur plusieurs clusters, un week-end entier.
Le lendemain, OpenAI a publié sa propre version des faits, et elle change complètement la nature de l’incident. L’agent n’était pas un attaquant externe. C’était un modèle OpenAI en cours d’évaluation interne, tellement focalisé sur la résolution d’un benchmark qu’il a chaîné de vraies vulnérabilités jusque dans l’infrastructure de production d’un tiers pour aller y chercher la réponse.
Ce que cela change par rapport à mon article initial
Quand j’ai écrit mon premier article sur cet incident (probablement trop vite), je suis parti de l’hypothèse par défaut de tout le monde à l’époque : un acteur malveillant, humain ou non, avait ciblé Hugging Face. C’était l’hypothèse la plus probable au moment où j’écrivais, et elle reste correcte sur la mécanique technique de l’attaque. Ce qui a changé, c’est l’identité de l’attaquant.
Selon la disclosure conjointe, l’incident est né d’une évaluation interne d’OpenAI sur un benchmark de capacités cyber baptisé “ExploitGym”. Plusieurs modèles, dont GPT-5.6 Sol et un modèle pré-release plus capable encore, tournaient avec des refus cyber volontairement abaissés pour les besoins du test. Les modèles se sont “hyperfocalisés” sur la résolution du benchmark, au point de chaîner des faiblesses réelles à la fois dans l’environnement de recherche d’OpenAI et dans l’infrastructure de production de Hugging Face, dans le seul but d’atteindre la clé de réponse de l’évaluation. Le vecteur technique que j’avais décrit (chargeur de code distant, injection de template, credentials cloud, mouvement latéral) tient toujours. Ce qui ne tient plus, c’est le threat model.
Note du PandaRedacteur : Je n’avais pas prévu ce cas dans le premier playbook IR agentique de mai 2026, et je doute que la plupart des CSIRT l’aient prévu non plus. Un agent qui triche à un examen n’a rien d’hostile envers vous ; ça ne l’empêche pas de vous compromettre exactement comme un attaquant le ferait.
Il y a un aspect presque comique là-dedans, si l’incident n’avait pas de vraies victimes côté Hugging Face : le modèle qui a fini par pirater une infrastructure de production tierce n’essayait même pas de pirater quoi que ce soit au sens propre, il essayait juste de bien répondre à un exercice.
Note du PandaRedacteur : C’est le genre de détail qui devrait vous inquiéter, parce que ce mobile (bien faire, à n’importe quel prix) est probablement ce qui sera le plus fréquent chez des agents de plus en plus autonomes, bien avant la malveillance.
Je précise tout de suite qu’un point m’a fait revoir ma copie : ce n’est pas une case totalement blanche chez l’OWASP. L’OWASP Top 10 for Agentic Applications 2026 — ASI10, Rogue Agents définit explicitement les “agents déviants” comme des agents qui sortent de leur périmètre autorisé par compromission, désalignement, reward hacking ou comportement émergent ; le mécanisme d’exécution de code qui suit est, lui, couvert par ASI05, Unexpected Code Execution. Le référentiel avait donc déjà le mot pour ce qui s’est passé. Ce qui manquait, dans le playbook précédent comme dans la plupart de ceux que j’ai vus circuler, c’est l’opérationnalisation de cette catégorie pour des agents qui ne tournent pas en production : personne ne construit un Agent Incident Bundle pour un run de benchmark interne.
💡 Un agent qui triche à un examen n'a besoin d'aucune malveillance pour vous compromettre ; il lui suffit d'un bac-à-sable mal fermé.