ExploitGym mesure un exploit, pas une attaque réelle

ExploitGym mesure une capacité offensive précise : transformer une vulnérabilité déjà reproduite en exploit capable d’obtenir une exécution de code non autorisée dans une cible contrôlée. Il ne mesure ni la découverte initiale d’une faille ni la probabilité qu’une intrusion complète réussisse contre une organisation.

Un score compte donc les tâches résolues par une configuration expérimentale — modèle, agent logiciel, outils, consignes, protections et temps alloué. Il ne constitue pas un taux de compromission applicable tel quel à un système de production.

La tâche commence après la découverte de la faille

L’agent ne reçoit pas un logiciel inconnu à auditer. Il dispose notamment du code vulnérable, des éléments de compilation, d’une entrée qui déclenche déjà le défaut, d’une description de la vulnérabilité, des exécutables nécessaires et d’une cible distante isolée. Son travail consiste à prolonger cette preuve de vulnérabilité jusqu’à un effet de sécurité concret.

Le préprint scientifique d’ExploitGym décrit un instantané de 898 instances issues de vulnérabilités réelles, réparties entre des programmes en espace utilisateur, le moteur JavaScript V8 et le noyau Linux. Les configurations sont placées dans des environnements conteneurisés reproductibles, avec des protections de sécurité variables afin d’en isoler l’effet.

Un succès prouve ainsi que l’agent a franchi l’étape séparant un défaut connu et reproductible d’un exploit fonctionnel dans l’environnement fourni. Il ne prouve pas que le même agent saurait repérer la faiblesse dans une version inconnue, sélectionner une cible, obtenir un accès initial, se déplacer dans un réseau, persister ou contourner une équipe de défense.

Le drapeau ne suffit pas sans validation de la faille

ExploitGym valide une capture de drapeau puis vérifie que l’agent a exploité la vulnérabilité prévue.

La cible contient un drapeau généré dynamiquement, inaccessible avec les privilèges normalement accordés. Pour le récupérer, l’agent doit exécuter du code à un niveau que le modèle de sécurité de la tâche est censé interdire. Un crash, une analyse correcte ou une primitive technique inachevée ne compte donc pas comme une résolution.

La capture du secret reste nécessaire, mais elle ne suffit pas. Un programme ancien peut comporter plusieurs défauts : l’agent pourrait atteindre le drapeau par une vulnérabilité différente ou par un raccourci sans rapport avec la tâche. L’analyse méthodologique d’Anthropic précise qu’un essai n’est accepté que si le bon drapeau est soumis et si un juge confirme l’exploitation de la vulnérabilité prévue.

Cette distinction explique pourquoi le total des drapeaux capturés peut dépasser le score principal. Le juge examine la trajectoire de l’agent et les éléments produits afin d’attribuer le résultat au défaut ciblé. Le benchmark ne récompense donc pas seulement l’effet final : il cherche aussi à vérifier le chemin technique qui l’a rendu possible.

Les protections changent la difficulté mesurée

Une tâche ExploitGym rejouée avec les protections activées bloque ou complique l’exploit initial.

ExploitGym permet d’activer ou de désactiver des mécanismes de durcissement adaptés à chaque famille de cibles. Ils comprennent notamment la randomisation de l’espace d’adressage, les exécutables indépendants de leur position et les canaris de pile pour certains programmes, le bac à sable du tas pour V8, ainsi que KASLR et des réglages liés aux espaces de noms utilisateur pour Linux.

Le protocole de référence commence avec les protections désactivées. Les tâches réussies peuvent ensuite être rejouées avec les défenses correspondantes afin de déterminer si l’exploit reste valable ou si l’agent sait adapter sa chaîne. Ces deux conditions ne répondent pas à la même question : la première isole davantage la construction de l’exploit, tandis que la seconde ajoute le contournement de mécanismes de durcissement.

Même une réussite avec les protections du benchmark activées ne reproduit pas automatiquement un déploiement réel. Les versions exactes, correctifs additionnels, règles réseau, droits disponibles, outils de détection et contrôles d’accès d’une organisation peuvent modifier profondément l’exploitabilité opérationnelle.

Le score appartient à une configuration et à un budget

Le résultat n’est pas une propriété intrinsèque du seul modèle de langage. Celui-ci fonctionne à travers un environnement agentique, par exemple Claude Code, Codex CLI ou Gemini CLI, qui détermine les outils accessibles, la gestion du contexte et la manière d’exécuter les commandes. Une ligne de résultats décrit donc une association modèle-agent dans des conditions déterminées.

Le protocole de référence accorde une tentative par tâche et une limite de deux heures en temps réel. Modifier ce budget peut modifier le résultat : certaines configurations atteignent rapidement un plateau, tandis que d’autres profitent d’un horizon plus long pour construire, tester et corriger leur exploit. Deux scores ne sont comparables que si le temps, le nombre d’essais, les consignes, les outils et l’état des protections correspondent.

Les évaluations de capacité peuvent également employer des conditions différentes de celles d’un produit commercial ordinaire, notamment en matière de filtres contre les requêtes cyber offensives. Le score décrit alors la capacité technique observée dans le dispositif expérimental, pas nécessairement le comportement accessible à tous les utilisateurs du produit.

Ce qu’un succès et un échec permettent de conclure

Pour un défenseur, une réussite signifie que la configuration évaluée a converti la vulnérabilité spécifiée en exécution de code non autorisée dans les conditions du test. Une réussite après activation des protections apporte une preuve plus exigeante de cette capacité, sans suffire à quantifier l’exposition d’une organisation.

Un échec est moins conclusif encore. Il peut refléter une difficulté d’exploitation, un refus du modèle, une mauvaise utilisation des outils, un budget insuffisant ou une instance qui ne peut pas être exploitée dans la configuration proposée. Le benchmark ne crédite pas les progrès intermédiaires qui n’aboutissent pas au drapeau et à la validation de la vulnérabilité prévue.

Enfin, le dénominateur doit accompagner tout score. Le journal des versions d’ExploitGym recense 869 instances dans la première distribution publique, contre 898 dans l’instantané évalué par le papier, après filtrage de cas considérés comme non exploitables. La différence ne réécrit pas les expériences antérieures : elle impose de vérifier la version du corpus avant de rapprocher deux résultats.

ExploitGym mesure le passage d’une faille à un exploit, pas une attaque réelle