Wir haben die XBOW-Benchmark-Suite gelöst — in unserer schnellsten Stufe

XBEN ist der offene Web-Exploitation-Benchmark, der von XBOW Engineering veröffentlicht wurde: 104 in sich geschlossene Webanwendungen, von denen jede eine Flag verbirgt. Um eine zu lösen, muss ein Agent eine echte Schwachstelle finden und ausnutzen — ein IDOR, eine Injection, einen Auth-Bypass, eine Template-Injection, ein XXE — und die Flag herausziehen. Sie hat sich zur Referenz-Suite für autonome Pentest-Agenten entwickelt.

Wir richteten dieselbe Engine, die die Scans unserer Kunden ausführt, auf alle 104 aus, Black-Box: eine laufende App und sonst nichts, kein Quellcode, keine Hinweise. Das Bemerkenswerte sind nicht die 100 % — XBOW selbst merkt an, dass die Suite branchenweit inzwischen weitgehend gelöst ist — es ist, welche Stufe es geschafft hat.

Das Ergebnis

Alle 104 gelöst, in der schnellen Stufe: unser schnellster, günstigster Scan-Modus, gestützt auf ein kleineres, schnelleres Modell. Da die schnellste Stufe die Suite bereits gelöst hatte, haben wir die langsameren Standard- und Deep-Stufen nicht mehr darauf ausgeführt.

Die 104 Challenges umfassen 26 verschiedene Schwachstellenklassen: XSS (23), Standard-Anmeldedaten (18), IDOR (15), Rechteausweitung (14), Server-Side Template Injection (13), Command Injection (11), Business-Logik (7), SQL Injection (6), Local File Inclusion (6), unsichere Deserialisierung (6), beliebiger Datei-Upload (6), Informationsoffenlegung (6), Path Traversal (5), XXE, SSRF, JWT, GraphQL, kryptografische Schwächen, Blind SQLi sowie Einzelfälle wie Request Smuggling, Race Conditions und NoSQL Injection.

Die durchschnittliche Lösungszeit betrug 9,7 Minuten pro Challenge; die schnellste waren 1,5 Minuten. Die gesamte Suite benötigte etwa 16,8 Stunden Rechenzeit, vollständig unbeaufsichtigt.

Wie eine Lösung bewertet wird

Jede XBEN-Flag ist deterministisch — sie wird aus dem Challenge-Namen abgeleitet und zur Build-Zeit in die App eingebacken. Ein Lauf zählt nur dann als gelöst, wenn die Engine autonom genau diese Flag entdeckt und meldet. Es gibt keine Teilpunkte und keinen Menschen im Ablauf: Die Engine erhält eine URL und die Anweisung, die Flag zu erbeuten, und entweder sie kommt mit dem richtigen FLAG{...} zurück oder nicht.

Warum die schnelle Stufe die Geschichte ist

Ergebnisse autonomer Pentests lassen sich leicht aufblähen: Gib einem Agenten Quellcode (White-Box), unbegrenzte Zeit, ein Spitzenmodell und ein paar Wiederholungen, und viele Suiten fallen um. Wir haben das Gegenteil getan. Das war Black-Box, ein einziger Durchlauf, unbeaufsichtigt, auf dem günstigsten Modell, das wir ausliefern. Dass ein schneller, kostengünstiger Scan eine Suite aus echten Exploitation-Challenges löst, ist der berichtenswerte Teil — denn das ist die Stufe, in der die meisten Scans unserer Kunden tatsächlich laufen.

Der ehrliche Teil

Eine Zahl wie 100 % verdient ihre Sternchen, also hier sind sie:

• XBEN ist ein Validierungsset. Es ist XBOWs eigene öffentliche Suite, entworfen, um lösbar zu sein, und inzwischen weithin gelöst. Ein perfektes Ergebnis ist eine Plausibilitätsprüfung für unsere Engine, keine Behauptung, dass wir „die Web-Sicherheit gelöst" hätten.
• Die Bewertung ist bewusst nachsichtig. Eine Challenge zählt, wenn die richtige Flag im Lauf auftaucht — so ist die Suite gedacht, und großzügig im Vergleich zu zielbasierten Benchmarks.
• Dieser Lauf lief über eine kostenpflichtige API. Black-box und unbeaufsichtigt. Er ist vollständig reproduzierbar — der Harness und jedes Log pro Challenge werden zusammen mit diesen Zahlen veröffentlicht.

Zum Vergleich: Bei CVE-Bench — einer härteren Suite mit strikter, zielbasierter Bewertung — löst dieselbe Engine einen deutlich geringeren Anteil (und wir stellten fest, dass einige ihrer „Fehlschläge" tatsächlich Bugs im Grader des Benchmarks waren). Verschiedene Benchmarks messen verschiedene Dinge; wir veröffentlichen beide.

Was es zum Ausführen brauchte

Einen vier Jahre alten Benchmark im Jahr 2026 durchgängig auszuführen, ist ein eigenes kleines Abenteuer. Zwei umgebungsbedingte Probleme mussten behoben werden, bevor auch nur eine einzige Challenge überhaupt bauen würde:

• Das neuere Docker-Compose-Plugin lehnt die expose: "3306:3306"-Syntax ab, die die älteren Challenges verwenden; bei den Datenbankdiensten mussten die Expose-Einträge auf einen einzelnen Port umgeschrieben werden.
• Rund vierzig Challenges basieren auf archivierten Debian-Basis-Images, deren Paket-Repositories nach archive.debian.org umgezogen sind, sodass apt-get 404s zurückgibt; ihre Dockerfiles brauchten ihre APT-Quellen, auf das Archiv umgezeigt.

Eine Handvoll einzelner Challenges brauchte außerdem Versions-Bumps — ein Python-Image, das alt genug war, dass eine Abhängigkeit nicht bauen wollte, eine Composer-Version, die nun ein per Advisory markiertes Paket blockiert, ein Node-Sidecar mit Syntax, die seine alte Laufzeit nicht parsen konnte. Nichts davon ist die Engine; es ist Benchmark-Bit-Rot und erwähnenswert für alle, die versuchen, den Lauf zu reproduzieren.

Ansehen oder ausführen

Die vollständige Aufschlüsselung — nach Schwierigkeit und Schwachstellenklasse, mit der Methodik — findet sich auf unserer Benchmark-Seite. Und die Engine, die diese 104 Ziele gelöst hat, ist dieselbe, die Ihre Scans ausführt: Richten Sie sie auf Ihre eigene Anwendung und sehen Sie, was sie findet.