Nous avons réussi toute la suite de benchmarks XBOW — dans notre palier le plus rapide

XBEN est le benchmark ouvert d'exploitation web publié par XBOW Engineering : 104 applications web autonomes, chacune cachant un flag. Pour en résoudre un, un agent doit trouver et exploiter une véritable vulnérabilité — un IDOR, une injection, un contournement d'authentification, une injection de template, un XXE — et en extraire le flag. C'est devenu la suite de référence pour les agents de pentest autonomes.

Nous avons dirigé le même moteur qui exécute les scans de nos clients sur les 104, en boîte noire : une application en cours d'exécution et rien d'autre, pas de source, pas d'indices. Le point notable n'est pas le 100% — XBOW eux-mêmes notent que la suite est désormais largement résolue dans tout le secteur — c'est quel palier l'a fait.

Le résultat

Les 104 résolus, dans le palier rapide : notre mode de scan le plus rapide et le moins cher, adossé à un modèle plus petit et plus rapide. Comme le palier le plus rapide avait déjà réussi la suite, nous n'y avons pas exécuté les paliers standard et approfondi, plus lents.

Les 104 défis couvrent 26 classes de vulnérabilités distinctes : XSS (23), identifiants par défaut (18), IDOR (15), élévation de privilèges (14), injection de template côté serveur (13), injection de commandes (11), logique métier (7), injection SQL (6), inclusion de fichier local (6), désérialisation non sécurisée (6), téléversement de fichier arbitraire (6), divulgation d'informations (6), traversée de répertoire (5), XXE, SSRF, JWT, GraphQL, failles cryptographiques, SQLi en aveugle, et cas isolés comme le request smuggling, les conditions de course et l'injection NoSQL.

Le temps de résolution moyen était de 9.7 minutes par défi ; le plus rapide était de 1.5 minute. La suite entière a nécessité environ 16.8 heures de calcul, entièrement sans surveillance.

Comment une résolution est évaluée

Chaque flag XBEN est déterministe — il est dérivé du nom du défi et intégré dans l'application au moment de la construction. Une exécution compte comme résolue uniquement lorsque le moteur découvre et signale de manière autonome ce flag exact. Il n'y a pas de crédit partiel ni d'humain dans la boucle : le moteur reçoit une URL et l'instruction de capturer le flag, et soit il revient avec le bon FLAG{...}, soit non.

Pourquoi le palier rapide est l'essentiel

Les résultats de pentest autonome sont faciles à gonfler : donnez à un agent le code source (boîte blanche), un temps illimité, un modèle haut de gamme et quelques nouvelles tentatives, et bon nombre de suites s'effondrent. Nous avons fait l'inverse. C'était en boîte noire, en une seule passe, sans surveillance, sur le modèle le moins cher que nous proposons. Qu'un scan rapide et peu coûteux réussisse une suite construite à partir de véritables défis d'exploitation, voilà ce qui mérite d'être rapporté — car c'est le palier dans lequel la plupart des scans de nos clients s'exécutent réellement.

La partie honnête

Un chiffre comme 100% mérite ses astérisques, alors les voici :

• XBEN est un ensemble de validation. C'est la propre suite publique de XBOW, conçue pour être résoluble et désormais largement résolue. Un score parfait est une vérification de bon sens de notre moteur, pas une affirmation selon laquelle nous aurions "résolu la sécurité web."
• L'évaluation est indulgente par conception. Un défi compte si le bon flag apparaît dans l'exécution — ce qui correspond à la manière dont la suite est censée être notée, et généreux par rapport aux benchmarks basés sur des objectifs.
• Cette exécution s'est faite sur une API payante. Black-box et sans intervention. Elle est entièrement reproductible — le harnais et chaque journal par défi sont publiés avec ces chiffres.

Par contraste, sur CVE-Bench — une suite plus difficile avec une évaluation stricte basée sur des objectifs — le même moteur résout une fraction bien plus faible (et nous avons découvert que certains de ses "échecs" étaient en réalité des bugs dans l'évaluateur du benchmark). Différents benchmarks mesurent différentes choses ; nous publions les deux.

Ce qu'il a fallu pour l'exécuter

Exécuter de bout en bout un benchmark vieux de quatre ans en 2026 est en soi une petite aventure. Deux problèmes d'environnement ont dû être corrigés avant même qu'un seul défi ne se construise :

• Le plugin Docker Compose plus récent rejette la syntaxe expose: "3306:3306" qu'utilisent les défis plus anciens ; les services de base de données ont eu besoin que leurs entrées expose soient réécrites vers un port unique.
• Une quarantaine de défis reposent sur des images de base Debian archivées dont les dépôts de paquets ont été déplacés vers archive.debian.org, si bien que apt-get renvoie des erreurs 404 ; leurs Dockerfiles ont eu besoin que leurs sources APT soient repointées vers l'archive.

Une poignée de défis individuels ont aussi nécessité des montées de version — une image Python assez ancienne pour qu'une dépendance ne se construise pas, une version de Composer qui bloque désormais un paquet signalé par un avis de sécurité, un sidecar Node utilisant une syntaxe que son ancien runtime ne pouvait pas analyser. Rien de tout cela ne relève du moteur ; c'est de la décrépitude du benchmark, et cela mérite d'être noté pour quiconque tente de reproduire l'exécution.

Voyez-le, ou exécutez-le

La ventilation complète — par difficulté et par classe de vulnérabilité, avec la méthodologie — se trouve sur notre page de benchmark. Et le moteur qui a réussi ces 104 cibles est celui qui exécute vos scans : dirigez-le vers votre propre application et voyez ce qu'il trouve.