XBEN es el benchmark abierto de explotación web publicado por XBOW Engineering: 104 aplicaciones web autónomas, cada una escondiendo una flag. Para resolver una, un agente tiene que encontrar y explotar una vulnerabilidad real — un IDOR, una inyección, un bypass de autenticación, una inyección de plantillas, un XXE — y extraer la flag. Se ha convertido en la suite de referencia para agentes de pentesting autónomos.
Apuntamos el mismo motor que ejecuta los escaneos de nuestros clientes a los 104, en caja negra: una aplicación en ejecución y nada más, sin código fuente, sin pistas. Lo notable no es el 100% — los propios de XBOW señalan que la suite ya está en gran medida resuelta en toda la industria — es qué nivel lo hizo.
El resultado
Los 104 resueltos, en el nivel rápido: nuestro modo de escaneo más veloz y económico, respaldado por un modelo más pequeño y rápido. Como el nivel más rápido ya superó la suite, no ejecutamos sobre ella los niveles estándar y profundo, que son más lentos.
| Dificultad | Resueltos | Tasa |
|---|---|---|
| Nivel 1 — Fácil | 45 / 45 | 100% |
| Nivel 2 — Medio | 51 / 51 | 100% |
| Nivel 3 — Difícil | 8 / 8 | 100% |
| Total | 104 / 104 | 100% |
Los 104 retos abarcan 26 clases distintas de vulnerabilidad: XSS (23), credenciales por defecto (18), IDOR (15), escalada de privilegios (14), inyección de plantillas del lado del servidor (13), inyección de comandos (11), lógica de negocio (7), inyección SQL (6), inclusión de archivos locales (6), deserialización insegura (6), subida arbitraria de archivos (6), divulgación de información (6), path traversal (5), XXE, SSRF, JWT, GraphQL, fallos criptográficos, SQLi a ciegas, y casos aislados como request smuggling, condiciones de carrera e inyección NoSQL.
El tiempo medio de resolución fue de 9.7 minutos por reto; el más rápido fue de 1.5 minutos. La suite completa consumió alrededor de 16.8 horas de cómputo, totalmente sin supervisión.
Cómo se puntúa una resolución
Cada flag de XBEN es determinista — se deriva del nombre del reto y se incrusta en la aplicación en tiempo de construcción. Una ejecución cuenta como resuelta solo cuando el motor descubre y reporta autónomamente esa flag exacta. No hay crédito parcial ni humano en el bucle: el motor recibe una URL y la instrucción de capturar la flag, y o vuelve con la FLAG{...} correcta o no lo hace.
Por qué el nivel rápido es lo importante
Los resultados de pentesting autónomo son fáciles de inflar: dale a un agente código fuente (caja blanca), tiempo ilimitado, un modelo de gama alta y unos cuantos reintentos, y muchas suites se desmoronan. Nosotros hicimos lo contrario. Esto fue en caja negra, de una sola pasada, sin supervisión, con el modelo más económico que ofrecemos. Que un escaneo rápido y barato supere una suite construida a partir de retos reales de explotación es la parte que vale la pena reportar — porque ese es el nivel en el que realmente se ejecutan la mayoría de los escaneos de nuestros clientes.
La parte honesta
Un número como el 100% merece sus asteriscos, así que aquí están:
- XBEN es un conjunto de validación. Es la propia suite pública de XBOW, diseñada para ser resoluble y ahora ampliamente resuelta. Una puntuación perfecta es una comprobación de cordura sobre nuestro motor, no una afirmación de que hemos "resuelto la seguridad web".
- La calificación es indulgente por diseño. Un reto cuenta si la flag correcta aparece en la ejecución — que es como se supone que debe puntuarse la suite, y generoso comparado con los benchmarks basados en objetivos.
- Esta ejecución se realizó sobre una API de pago. Black-box y sin intervención. Es totalmente reproducible — el harness y cada registro por reto se publican junto a estas cifras.
En contraste, en CVE-Bench — una suite más difícil con calificación estricta basada en objetivos — el mismo motor resuelve una fracción mucho menor (y descubrimos que algunos de sus "fallos" eran en realidad errores en el calificador del benchmark). Distintos benchmarks miden cosas distintas; publicamos ambos.
Lo que costó ejecutarlo
Ejecutar de principio a fin un benchmark de cuatro años en 2026 es su propia pequeña aventura. Hubo que arreglar dos problemas del entorno antes de que un solo reto siquiera se construyera:
- El plugin más nuevo de Docker Compose rechaza la sintaxis
expose: "3306:3306"que usan los retos más antiguos; los servicios de base de datos necesitaron que sus entradas de expose se reescribieran a un único puerto. - Aproximadamente cuarenta retos están construidos sobre imágenes base de Debian archivadas cuyos repositorios de paquetes se han movido a
archive.debian.org, por lo queapt-getdevuelve 404; sus Dockerfiles necesitaron que sus fuentes APT se reapuntaran al archivo.
Un puñado de retos individuales también necesitó actualizaciones de versión — una imagen de Python lo bastante antigua como para que una dependencia no compilara, una versión de Composer que ahora bloquea un paquete marcado por un aviso, un sidecar de Node usando sintaxis que su viejo runtime no podía parsear. Nada de eso es el motor; es el deterioro del benchmark, y vale la pena señalarlo para quien intente reproducir la ejecución.
Míralo, o ejecútalo
El desglose completo — por dificultad y clase de vulnerabilidad, con la metodología — está en nuestra página de benchmark. Y el motor que superó estos 104 objetivos es el mismo que ejecuta tus escaneos: apúntalo a tu propia aplicación y mira lo que encuentra.