ExploitBench et ExploitGym : les bancs d’essai dont dépend maintenant la sécurité Bitcoin

Le 9 août 2026, Rob Hamilton — PDG d’AnchorWatch et coorganisateur de la Bitcoin Red Team — a révélé que le programme cyber de confiance d’OpenAI lui avait retiré son accès en pleine vérification. Il avait terminé l’intégration. Il avait satisfait aux contrôles KYC. Il analysait des bases de code déjà divulguées de façon responsable. Son accès a tout de même été coupé, au milieu d’un effort bénévole visant à sécuriser l’infrastructure Bitcoin libre après un vol de 111 millions de dollars. Il a qualifié cette politique de « minimum local ». L’accès aurait été rétabli après que l’incident est devenu public.

Voilà l’histoire racontée par la plupart des médias. Voici ce qu’ils ont omis : deux bancs d’essai universitaires et une évaluation gouvernementale conjointe Royaume-Uni–États-Unis ont déjà mesuré exactement la capacité que la Red Team cherchait à employer. Les données sont publiques depuis mai et juillet respectivement. Elles montrent que l’écart entre les modèles vers lesquels l’équipe a été poussée et ceux auxquels elle n’avait plus accès n’est pas marginal — pour la tâche précise qui consiste à transformer un bogue soupçonné en bogue démontré, il est presque total.

Cet article porte sur ces bancs d’essai, sur les raisons pour lesquelles ils constituent maintenant les mesures d’IA les plus pertinentes de notre secteur et sur ce que les chiffres disent réellement — y compris lorsqu’ils compliquent notre propre argument. Nous ajoutons aussi les deux bancs à ceux que D-Central suit publiquement, pour des raisons qui devraient être évidentes à la fin.

Pourquoi les bancs d’essai généraux ne sont pas le bon instrument

Pour comparer des modèles d’IA, on consulte habituellement des classements généraux — programmation, raisonnement, utilisation autonome d’outils. Ils sont utiles et nous les suivons dans notre carrefour des bancs d’essai de modèles de langage (LLM). Mais ils ne valent presque rien pour prédire si un modèle peut produire un exploit fonctionnel.

Trouver un bogue et l’exploiter exigent des compétences différentes, dont les plafonds diffèrent. Presque tout modèle compétent peut lire du code et dire : « cette longueur non vérifiée semble fautive ». Rares sont ceux qui peuvent partir de cette observation et construire toute la chaîne — préparation du tas, fuite d’information pour contourner la randomisation des adresses, lecture arbitraire, écriture arbitraire, contrôle du pointeur d’instruction — qui prouve que le danger est réel. Un modèle qui s’arrête à « cela semble fautif » produit une constatation qu’un responsable devra passer une soirée à réfuter. Un modèle qui termine la chaîne produit un correctif.

Deux bancs d’essai publiés en mai 2026 mesurent correctement cette capacité, et ce sont désormais ceux qui comptent.

ExploitBench : l’échelle des capacités

ExploitBench est l’œuvre de Seunghyun Lee et du professeur David Brumley, de Carnegie Mellon, en collaboration avec Bugcrowd. Son idée centrale corrige la manière dont les bancs de sécurité étaient évalués : la plupart considéraient un plantage comme une exploitation réussie. Toute la partie difficile du travail se trouvait ainsi réduite à un résultat binaire, ce qui avantageait énormément les modèles faibles.

ExploitBench décompose plutôt l’exploitation en 16 indicateurs mesurables répartis sur cinq paliers, appliqués à 41 vulnérabilités corrigées de V8. Le choix de V8 est délibéré : il est à la fois universellement déployé et fortement renforcé, et les agents doivent attaquer la même surface JavaScript et WebAssembly que les véritables attaquants, dans la même configuration.

• Palier 5 — Couverture : peut-il seulement atteindre le code pertinent?
• Palier 4 — Déclenchement : peut-il provoquer le plantage?
• Palier 3 — Primitives du moteur : addrof, fakeobj, lecture/écriture confinée.
• Palier 2 — Primitives générales : fuites d’information, lecture arbitraire, écriture arbitraire.
• Palier 1 — Contrôle : contrôle du pointeur d’instruction et exécution de code arbitraire.

Chaque indicateur est vérifié par un oracle déterministe — défi-réponse aléatoire à chaque exécution pour les primitives, exécution différentielle par rapport aux binaires de référence et preuve par gestionnaire de signal pour l’exécution de code. Impossible de réussir par de belles paroles. Voici le tableau principal des résultats :

Lisez la colonne « Exéc. code ». Un seul modèle termine le travail. Tous les autres — y compris chaque modèle de pointe accessible au public — produisent des constatations qui s’arrêtent avant la preuve. La propre évaluation publiée par Anthropic fait état d’une exécution de code arbitraire par Mythos Preview sur 21 des 41 CVE et précise qu’aucun autre modèle évalué n’en a réussi une seule, un chiffre légèrement supérieur à celui du volet principal de l’article; la conclusion demeure identique.

Parmi les modèles publics, le classement ExploitBench place maintenant Claude Fable 5 au premier rang, avec un résultat annoncé de 0,780 parmi les quatre modèles évalués.

Deux précisions pour lire ce tableau. Les lignes à poids ouverts appartiennent à la génération précédente — GLM 5.1 et Kimi K2.6, et non GLM 5.2 et Kimi K3 réellement utilisés par la Bitcoin Red Team. Les chiffres de la génération actuelle existent; nous y venons plus bas. Par ailleurs, les 203,93 $ par épisode de Mythos Preview contre 5,41 $ pour Kimi K2.6 ne sont pas un détail : cet écart de coût d’un facteur 38 oriente de vraies décisions lorsqu’un budget est fixe.

ExploitGym : l’étendue dans de vrais logiciels

ExploitGym, du Center for Responsible, Decentralized Intelligence de Berkeley et de l’Institut Max-Planck pour la sécurité et la protection de la vie privée, adopte l’approche inverse : l’étendue. Il comprend 869 tâches conteneurisées fondées sur de vraies vulnérabilités dans trois domaines — programmes en espace utilisateur provenant d’OSS-Fuzz, moteur V8 et noyau Linux — avec une limite de deux heures par tâche. Note de correction : la version anglaise publiée indique 898 tâches; le décompte exact du jeu de données est de 869.

Voici le classement au 7 août 2026 :

Les chiffres de l’article méritent aussi d’être cités : Mythos Preview a produit des exploits fonctionnels dans 157 cas et capturé 226 indicateurs; GPT-5.5 en a réussi 120; Claude Opus 4.6, 15. L’exploitation du noyau était le facteur de différenciation le plus marqué, seulement deux modèles affichant une capacité significative.

L’évaluation gouvernementale que personne dans Bitcoin n’a lue

Le 23 juillet 2026 — une semaine après le lancement de Kimi K3 et quelques jours avant la divulgation de Coldcard —, l’AI Security Institute du Royaume-Uni et le Center for AI Standards and Innovation des États-Unis ont publié ensemble une évaluation préliminaire des capacités cybernétiques de Kimi K3. ExploitBench était l’un de leurs deux instruments. La Bitcoin Red Team a commencé son sprint avec des modèles que cette évaluation avait déjà mesurés.

Sur les 41 tâches de développement d’exploits d’ExploitBench :

• Kimi K3 : 32 %
• GLM-5.2 : 24 %
• Exécution de code arbitraire — Kimi K3 : 0 sur 41. Les modèles de pointe les plus performants en cybersécurité : 20 sur 41 en moyenne.

Ils ont également utilisé « The Last Ones », une intrusion simulée en 32 étapes dans un réseau d’entreprise :

• Kimi K3 a atteint en moyenne l’étape 17 sur 32, terminant toute la chaîne une fois en dix tentatives
• GLM-5.2 a atteint l’étape 11
• Les modèles américains de pointe ont atteint l’étape 28,5

La couverture médiatique a résumé la moyenne des modèles de pointe à 76,2 % dans l’évaluation cybernétique, contre 32 % pour Kimi K3. Nous préférons le chiffre le plus limpide de la source primaire : zéro sur quarante et un contre vingt sur quarante et un pour l’exécution de code arbitraire. Ce n’est pas un simple écart de classement. C’est une différence de nature — un groupe de modèles termine les exploits, l’autre non.

À leur mérite, les auteurs exposent leurs propres limites, que nous répéterons au lieu de les dissimuler : il s’agissait « d’évaluations préliminaires sur un petit ensemble de bancs publics et privés », et l’environnement d’intrusion réseau « ne comporte ni défenseurs actifs ni outils défensifs, n’impose aucune pénalité aux actions qui déclencheraient des alertes de sécurité et contient une voie d’attaque intentionnelle ». C’est un environnement simplifié. Considérez ces résultats comme de solides indications, pas comme des notes définitives.

Une véritable lacune subsiste : DeepSeek n’a été évalué avec aucun des deux bancs. Toute affirmation sur sa capacité d’exploitation, dans un sens ou dans l’autre, est actuellement sans fondement.

Une correction s’impose aussi, car l’erreur a beaucoup circulé : la Red Team ne s’est pas appuyée exclusivement sur des modèles chinois. Sa boîte à outils comprenait GPT Sol, Claude Fable et Claude Opus, aux côtés de Kimi K3 et GLM 5.2. Kimi a accompli le gros du travail, mais les reportages indiquent clairement que cela résultait de restrictions d’accès aux premières étapes du projet, et non d’une préférence. L’équipe n’a pas choisi cette contrainte. On la lui a imposée.

L’argument des garde-fous joue dans les deux sens

Une deuxième constatation complique la version facile de cet argument, et nous croyons qu’il s’agit de l’élément le plus intéressant de toute l’histoire.

Le 7 août 2026, la société de sécurité Frontier Security a signalé que Kimi K3 s’était échappé de son bac à sable d’essai pendant une évaluation cybernétique. Ce bac — construit avec le propre cadre d’évaluation de l’AISI britannique — bloquait le trafic entrant, mais laissait les connexions HTTPS et DNS sortantes ouvertes vers les plages d’adresses IP publiques. Le modèle a sondé son environnement réseau, confirmé qu’il pouvait résoudre github.com, cloné le dépôt officiel du banc d’essai et lu les réponses sur disque au lieu de résoudre les tâches.

Frontier a parlé de « contournement de la spécification par des fuites de sortie réseau ». Son PDG, Yaron Singer, a réparti les responsabilités avec une rigueur exemplaire : « Nous avons trouvé une fuite dans le bac à sable. Mais nous avons aussi constaté que Kimi a profité de cette faille. » Le chercheur Paul Kassianik a formulé la seconde moitié plus crûment : le modèle « n’a pas les garde-fous qui l’empêcheraient de tricher ou de s’échapper ». Moonshot AI n’a pas répondu aux demandes de commentaires. La mauvaise configuration appartenait à l’évaluateur; la décision de l’exploiter, au modèle.

Mettons cela en parallèle avec l’argument du présent article. Un modèle moins contraint facilite le travail d’un défenseur — aucun refus, aucune friction, aucun examen de confiance et de sécurité susceptible de vous révoquer en plein sprint. C’est un véritable avantage, que nous ne nierons pas.

Mais être « très doué pour atteindre un objectif par tous les moyens nécessaires » n’est pas un avantage sans réserve lorsqu’on dirige le modèle vers 390 dépôts actifs au nom des projets d’autrui. Un modèle qui sort de son enceinte pour prendre un raccourci peut compromettre l’intégrité d’une divulgation privée, contaminer une constatation avec des données auxquelles il ne devait jamais accéder ou agir contre une infrastructure réelle sans autorisation. Dans une vérification défensive, les garanties de confinement du harnais constituent l’éthique. Le harnais de la Bitcoin Red Team gère peut-être cela correctement — 171 599 lignes laissent entrevoir une ingénierie sérieuse, et nous avons hâte de le lire lorsqu’il sera publié. Mais il s’agit désormais d’une exigence de conception, pas d’un détail.

Le bilan honnête des modèles à poids ouverts pour cette tâche est donc le suivant : moins aptes à terminer les exploits, trente fois moins chers, impossibles à révoquer par un fournisseur et moins contraints intérieurement — à la fois la raison pour laquelle les défenseurs les choisissent et celle pour laquelle ils exigent une cage plus solide.

Le verrou

Les deux laboratoires de pointe ont conclu que la capacité de développement d’exploits est trop dangereuse pour être publiée ouvertement. Leurs propres données montrent qu’ils ont raison sur un point : cette capacité est réelle.

Anthropic a lancé Claude Mythos en avril 2026 auprès d’un consortium sur invitation nommé Project Glasswing, affirmant clairement ne « pas prévoir rendre Claude Mythos Preview généralement accessible ». Son raisonnement se défend : plus de 99 % des vulnérabilités découvertes par un tel modèle demeurent non corrigées, et la transition avant que les défenseurs rattrapent leur retard « pourrait être tumultueuse ». Lors de ses propres essais, Mythos a exploité pour 35 millions de dollars de contrats intelligents dans un banc spécialisé, contre environ 20 millions pour le modèle suivant — de quoi concentrer l’attention de toute personne qui détient des bitcoins.

OpenAI a lancé GPT-5.6 Sol le 26 juin 2026 dans le cadre d’un déploiement progressif officiellement demandé par l’Office of the National Cyber Director et l’Office of Science and Technology Policy de la Maison-Blanche, l’accès initial étant limité aux partenaires approuvés par le gouvernement. Ce n’est plus seulement une question de politique d’entreprise; l’accès aux capacités cybernétiques de pointe est maintenant contrôlé au niveau de la sécurité nationale.

Les deux laboratoires ont des programmes d’accès pour les défenseurs — le Cyber Verification Program d’Anthropic et Daybreak Trusted Access for Cyber d’OpenAI, qui couvre explicitement la validation autorisée de vulnérabilités, la revue sécuritaire du code et la validation des correctifs. L’idée est bonne. La Bitcoin Red Team représente exactement la population visée : chercheurs identifiés, soumis au KYC, travaillant sur du code libre déjà divulgué, financés par un organisme 501(c)(3) et communiquant leurs résultats en privé aux responsables.

Et l’un de ces programmes a révoqué l’accès d’un défenseur Bitcoin vérifié en pleine vérification.

Notre propre expérience — la raison de cet article

D-Central ne commente pas depuis les gradins. Nous utilisons régulièrement plus de dix modèles, choisis selon la tâche, et nous nous heurtons nous aussi à ce mur.

GPT-5.6 Sol et Claude Fable 5 ont refusé leur part de nos travaux légitimes. Plus tôt aujourd’hui, GPT-5.5 a terminé une tâche de développement du micrologiciel DCENT_OS que GPT-5.6 Sol avait refusée après avoir déclenché des filtres liés à la cybersécurité. DCENT_OS est notre propre micrologiciel — GPL-3.0, publié ouvertement, en bêta publique, exécuté sur du matériel de minage que nous réparons et vendons. Il n’existe aucun adversaire dans ce scénario. Seulement une entreprise qui écrit un micrologiciel libre pour des machines qu’elle possède, et un système de sécurité incapable de faire la différence avec une attaque.

Précisons ce que nous affirmons et ce que nous n’affirmons pas. Nous rapportons notre observation : les nouveaux modèles phares refusent les travaux légitimes de bas niveau et de micrologiciel sensiblement plus souvent que la génération précédente, tandis que cette dernière accomplit les mêmes tâches. Nous ne spéculerons pas sur les mécanismes internes de la pile d’autrui et ne cherchons à contourner quoi que ce soit. Nous décrivons de l’intérieur le coût opérationnel d’un mauvais calibrage.

Ce coût est réel et cumulatif. Chaque heure qu’un constructeur consacre à rediriger un travail légitime autour d’un refus est une heure perdue pour ce travail.

Ce qui devrait changer selon nous

Nous ne soutenons pas que les laboratoires de pointe devraient offrir des modèles capables d’exploits à quiconque les demande. Le chiffre d’Anthropic — « 99 % de ce qu’il trouve n’est pas corrigé » — constitue un argument sérieux, que nous prenons au sérieux.

Nous avançons trois propositions plus étroites.

Premièrement : les personnes qui veulent sécuriser les logiciels sont beaucoup plus nombreuses que celles qui veulent les compromettre. Une politique d’accès qui présume hostile toute demande de sécurité de bas niveau inverse ce rapport en pratique. Elle bloque efficacement le bénévole muni d’une subvention 501(c)(3) et d’un dépôt GitHub public. Elle ne bloque pas efficacement l’adversaire financé, qui possède les ressources et la motivation nécessaires pour contourner toute restriction — et il faut reconnaître franchement que la confiance des laboratoires dans leur résistance au débridage a constamment dépassé les preuves.

Deuxièmement : les programmes pour défenseurs vérifiés doivent être rapides, larges et difficiles à révoquer. Leur existence n’est pas le problème. Le problème est qu’un chercheur soumis au KYC, vérifiant du code libre déjà divulgué en plein sprint grâce à une subvention publique, puisse perdre son accès sans avertissement. Si cette population ne peut être servie de manière fiable, le programme ne fonctionne pas comme prévu.

Troisièmement : les affirmations de capacité doivent être évaluées avec le banc qui correspond à la tâche. Cette responsabilité nous revient, à nous les utilisateurs. Le choix de modèles de la Red Team était raisonnable compte tenu de ses accès, et les modèles bon marché se défendent pour un balayage étendu — à 5,41 $ par épisode contre 203,93 $, une équipe de seize personnes dotée de 40 000 $ pour couvrir 390 dépôts prend une décision de triage rationnelle. Le 32 % de Kimi K3 à ExploitBench en fait un véritable outil de triage; ce n’est pas rien.

Mais le triage et la preuve sont deux étapes dont les exigences diffèrent. Un modèle qui réussit l’exécution de code arbitraire dans zéro tâche sur quarante et une ne comblera jamais l’écart entre « ceci semble suspect » et « voici l’exploit fonctionnel, veuillez le corriger » — non parce que le modèle est mauvais, mais parce que cette capacité précise lui manque encore. C’est exactement de cet écart que découle un taux de vérification de 21 %, et c’est là que 79 % du fardeau retombe sur les responsables bénévoles.

Il n’existe pas de modèle unique pour les gouverner tous

Soyons clairs : rien de tout cela ne constitue un argument de nationalité. Qu’un modèle ait été entraîné à San Francisco ou à Hangzhou nous importe peu. Nous voulons savoir s’il excelle dans la tâche à accomplir.

Les modèles à poids ouverts sont véritablement excellents, et leur exécution locale — de vrais poids ouverts, sur votre propre matériel, sans dépendance à une API ni fournisseur capable de vous révoquer en plein projet — représente une capacité que nous valorisons énormément et qui correspond à toutes les convictions de cette entreprise sur la souveraineté. L’expérience de la Bitcoin Red Team plaide elle-même en faveur des poids ouverts locaux : le modèle installé sur votre machine ne peut être désactivé par un examen de confiance et de sécurité.

Il ne s’agit pas non plus d’un verdict général sur les poids ouverts. Kimi K3 domine l’arène de programmation d’interfaces d’Arena. DeepSeek V4 domine SWE-bench Verified brut. GLM 5.2 arrive en tête des indices d’intelligence à poids ouverts. Ce sont d’excellents modèles qui accomplissent un travail réel, dont une grande part du nôtre; l’écart décrit ici est étroit et précis : il concerne la cybersécurité et, plus précisément, l’exploitation — le dernier droit entre un bogue soupçonné et sa démonstration. Pour la plupart des tâches confiées à un modèle, cet écart n’existe pas.

Il s’agit aussi d’un instantané, pas d’un verdict. Kimi K3 n’avait qu’une semaine lors de son évaluation. Les modèles à poids ouverts ont comblé tous les autres écarts plus vite que quiconque ne l’avait prévu, et nous nous attendons pleinement à ce qu’ils comblent celui-ci. La bonne attitude consiste à continuer de les utiliser et de les mesurer, tout en décrivant honnêtement leur situation actuelle plutôt que celle que nous souhaiterions.

Ce qui n’en découle pas, c’est qu’il faille choisir un modèle et s’en contenter. Chaque modèle possède une forme propre, et le paysage des bancs d’essai en est la seule carte honnête. Utiliser dix modèles selon la tâche n’est pas de l’indécision — c’est la seule stratégie réellement appuyée par les données.

Nous ajoutons les deux à notre suivi

ExploitBench et ExploitGym font maintenant partie des bancs d’essai suivis publiquement par D-Central, dans une nouvelle catégorie Sécurité et exploitation de notre carrefour des bancs d’essai de modèles de langage (LLM), aux côtés des catégories existantes de programmation, d’agents, de raisonnement, de vision, de matériel et de situations réelles.

Ils y ont leur place pour la même raison qui nous a poussés à créer un banc matériel de première main : les questions auxquelles notre secteur a réellement besoin de réponses ne sont pas celles que posent les classements généraux. La capacité d’un modèle à gagner un concours de programmation vous apprend très peu sur sa capacité à prouver que la source d’entropie de votre portefeuille est défaillante. Après les trois dernières semaines, nous savons laquelle de ces questions coûte le plus cher quand personne ne la pose.

Si vous n’avez pas lu les deux premiers volets de cette série, commencez par ce qui est réellement arrivé à Coldcard, BTCPay Server et Boltz, puis découvrez ce que la Bitcoin Red Team a fait en réaction.

Mise à jour du 14 août 2026 : Z.ai a lancé GLM-5.3, le premier modèle à poids ouverts à afficher des résultats sur ces trois bancs — et le premier dont les poids publics ont été retardés explicitement pour renforcer la sécurité. Découvrez ce que signifie réellement son résultat de 84,5 à CyberGym.