Abbiamo superato la suite di benchmark XBOW — nel nostro livello più veloce

XBEN è il benchmark aperto di sfruttamento web pubblicato da XBOW Engineering: 104 applicazioni web autonome, ciascuna con una flag nascosta. Per risolverne una, un agente deve trovare e sfruttare una vulnerabilità reale — un IDOR, un'injection, un bypass di autenticazione, una template injection, un XXE — ed estrarre la flag. È diventata la suite di riferimento per gli agenti di pentest autonomi.

Abbiamo puntato lo stesso motore che esegue le scansioni dei nostri clienti su tutte le 104, in modalità black-box: un'app in esecuzione e nient'altro, nessun codice sorgente, nessun suggerimento. La parte notevole non è il 100% — XBOW stessa osserva che la suite è ormai in gran parte risolta in tutto il settore — è quale livello l'ha fatto.

Il risultato

Tutte le 104 risolte, nel livello veloce: la nostra modalità di scansione più rapida ed economica, supportata da un modello più piccolo e più veloce. Poiché il livello più veloce aveva già superato la suite, non abbiamo eseguito su di essa i livelli standard e deep, più lenti.

Le 104 sfide coprono 26 distinte classi di vulnerabilità: XSS (23), credenziali di default (18), IDOR (15), escalation di privilegi (14), server-side template injection (13), command injection (11), business logic (7), SQL injection (6), local file inclusion (6), deserializzazione insicura (6), caricamento arbitrario di file (6), divulgazione di informazioni (6), path traversal (5), XXE, SSRF, JWT, GraphQL, difetti crittografici, blind SQLi e casi isolati come request smuggling, race condition e NoSQL injection.

Il tempo medio di risoluzione è stato di 9.7 minuti per sfida; la più veloce è stata di 1.5 minuti. L'intera suite ha richiesto circa 16.8 ore di calcolo, in modo completamente autonomo.

Come viene valutata una risoluzione

Ogni flag XBEN è deterministica — è derivata dal nome della sfida e integrata nell'app in fase di build. Un'esecuzione conta come risolta solo quando il motore scopre e riporta autonomamente esattamente quella flag. Non c'è credito parziale né intervento umano: il motore riceve un URL e l'istruzione di catturare la flag, e o torna con la FLAG{...} giusta oppure no.

Perché il livello veloce è la vera notizia

I risultati di pentest autonomo sono facili da gonfiare: date a un agente il codice sorgente (white-box), tempo illimitato, un modello di fascia alta e qualche tentativo, e molte suite crollano. Noi abbiamo fatto l'opposto. Questo era black-box, a passaggio singolo, non presidiato, sul modello più economico che offriamo. Che una scansione veloce ed economica superi una suite costruita da vere sfide di sfruttamento è la parte che vale la pena riportare — perché quello è il livello in cui girano effettivamente la maggior parte delle scansioni dei nostri clienti.

La parte onesta

Un numero come 100% merita i suoi asterischi, quindi eccoli:

• XBEN è un set di validazione. È la suite pubblica di XBOW stessa, progettata per essere risolvibile e ormai ampiamente risolta. Un punteggio perfetto è un controllo di integrità del nostro motore, non un'affermazione di aver "risolto la sicurezza web".
• La valutazione è indulgente per progettazione. Una sfida conta se la flag corretta appare nell'esecuzione — che è il modo in cui la suite è pensata per essere valutata, e generoso rispetto ai benchmark basati su obiettivi.
• Questa esecuzione è avvenuta su un'API a pagamento. Black-box e non presidiata. È pienamente riproducibile — l'harness e ogni log per singola sfida sono pubblicati insieme a questi numeri.

Per contrasto, su CVE-Bench — una suite più difficile con valutazione rigorosa basata su obiettivi — lo stesso motore risolve una frazione molto più bassa (e abbiamo scoperto che alcuni dei suoi "fallimenti" erano in realtà bug nel grader del benchmark). Benchmark diversi misurano cose diverse; noi pubblichiamo entrambi.

Cosa è servito per eseguirlo

Eseguire end-to-end nel 2026 un benchmark vecchio di quattro anni è una piccola avventura a sé. Due problemi ambientali sono dovuti essere risolti prima che anche una sola sfida potesse essere costruita:

• Il più recente plugin Docker Compose rifiuta la sintassi expose: "3306:3306" usata dalle sfide più vecchie; i servizi di database hanno avuto bisogno che le loro voci expose venissero riscritte a una singola porta.
• Circa quaranta sfide sono costruite su immagini di base Debian archiviate i cui repository di pacchetti si sono spostati su archive.debian.org, quindi apt-get restituisce errori 404; i loro Dockerfile hanno avuto bisogno che le loro sorgenti APT venissero ridirette all'archivio.

Una manciata di singole sfide ha avuto bisogno anche di aggiornamenti di versione — un'immagine Python abbastanza vecchia da non riuscire a compilare una dipendenza, una versione di Composer che ora blocca un pacchetto segnalato da un advisory, un sidecar Node che usa una sintassi che il suo vecchio runtime non riusciva ad analizzare. Nulla di tutto ciò è il motore; è bit-rot del benchmark, e vale la pena segnalarlo a chiunque provi a riprodurre l'esecuzione.

Guardalo, o eseguilo

La ripartizione completa — per difficoltà e classe di vulnerabilità, con la metodologia — si trova sulla nostra pagina del benchmark. E il motore che ha superato questi 104 bersagli è lo stesso che esegue le tue scansioni: puntalo sulla tua applicazione e guarda cosa trova.