El sistema de menús se implementará en un módulo de configuración/setup dedicado. Esto podría ser simplemente una función que imprime prompts y recopila la entrada, con valores predeterminados sensatos si el usuario presiona Enter (por ejemplo, user-agent predeterminado a uno estándar, timeout predeterminado = 10 segundos, sin proxy, sin salida a archivo). Esto mantiene la interacción clara y permite que el script se ejecute también de forma no interactiva (si más adelante agregamos argumentos de línea de comandos, podemos omitir los prompts interactivos proporcionando toda la configuración necesaria mediante args).

🚀 Concurrencia y mejoras de rendimiento

El rendimiento es crucial para un escáner, especialmente si se encuentran muchos endpoints. El script empleará concurrencia para la velocidad, ya sea mediante multihilo o asyncio (o una combinación):

• Escaneo multihilo: Dado que el escaneo de las rutas descubiertas (enviar solicitudes HTTP con encabezados) es una tarea limitada por E/S (I/O-bound), podemos usar hilos de Python de forma segura para paralelizarla. Las operaciones de E/S liberan el Global Interpreter Lock, lo que permite que múltiples hilos avancen de forma concurrente en las solicitudes de red. Usando concurrent.futures.ThreadPoolExecutor, podemos tener un grupo de hilos de trabajo, cada uno manejando un subconjunto de las tareas de escaneo. Esto puede acelerar drásticamente el proceso: por ejemplo, ejecutar 5 hilos en paralelo podría reducir el tiempo de escaneo aproximadamente por un factor de 5, como se muestra en otros contextos de web scraping. Permitiremos que el número de hilos sea configurable o elegiremos un valor predeterminado sensato (como 10 hilos) que equilibre la velocidad y la carga del servidor. Cada hilo tomará URL de una cola compartida de endpoints a probar.

• Alternativa con asyncio: Alternativamente, se puede usar un enfoque asíncrono, especialmente si se usa Playwright en modo async o httpx para las solicitudes HTTP. Podríamos await múltiples solicitudes simultáneamente. Por ejemplo, httpx.AsyncClient puede enviar muchas solicitudes de forma concurrente y recopilar los resultados. Este enfoque evita la sobrecarga de los hilos y puede ser muy eficiente para un gran número de endpoints. Sin embargo, mezclar asyncio con Playwright (que a su vez se puede usar de forma asíncrona) podría complicar las cosas. Una solución pragmática es usar threading para la fase de escaneo HTTP (ya que el rastreo con Playwright podría ser más fácil de gestionar en modo síncrono).

• Rastreo concurrente: También deberíamos considerar paralelizar el rastreo si el sitio es grande. Playwright puede abrir múltiples páginas a la vez usando un contexto async. Podríamos implementar una concurrencia limitada (por ejemplo, 2-3 páginas a la vez) para el rastreo. Por ejemplo, a medida que extraemos nuevas URL, podríamos lanzar una nueva Page para cada una si usamos asyncio. Esto puede ser una optimización avanzada si es necesario. Inicialmente, un rastreo de un solo hilo es más simple y adecuado para sitios de tamaño moderado, pero el diseño puede señalarlo como un punto de mejora.

• Seguridad de hilos (thread-safety): Garantizaremos el manejo seguro de los datos compartidos entre hilos. La lista de URL a escanear se puede procesar con ThreadPoolExecutor.map por simplicidad, o podemos usar una cola segura para hilos (queue.Queue de Python) y hacer que los hilos tomen elementos de ella hasta que esté vacía. El conjunto visited para el rastreo solo es accedido por el rastreador (un solo hilo, a menos que hagamos rastreo concurrente). Los hilos del escáner solo leerán de su lista de URL (sin modificar estructuras compartidas, excepto quizás el registro de resultados, que podemos proteger con un bloqueo o simplemente recopilar en una lista segura para hilos).

• Límite de velocidad (rate limiting) y cortesía: Dado que esta es una herramienta de pruebas de seguridad, la velocidad es una prioridad, pero aún así podríamos querer evitar sobrecargar el objetivo. Se puede aconsejar al usuario establecer un número razonable de hilos. También podemos implementar un pequeño retraso o usar semáforos para limitar la concurrencia si es necesario. Por ejemplo, podríamos no lanzar todos los hilos a la vez si la red del usuario o el servidor pudieran saturarse. En un escenario avanzado, un enfoque asíncrono podría usar un semáforo para permitir, digamos, 5 solicitudes concurrentes a la vez. Estos detalles se pueden ajustar en función de las pruebas de rendimiento del script.

En resumen, la concurrencia se aplicará principalmente a la fase de escaneo para probar múltiples endpoints en paralelo. Esto hace que el escáner sea mucho más rápido sin sacrificar mucha precisión (ya que cada solicitud es independiente). Como señala una referencia, “El multihilo con concurrent.futures puede dar un impulso significativo aquí. Podemos ejecutar tareas de E/S de forma concurrente en múltiples hilos y ver una gran aceleración”. El multihilo es adecuado aquí porque las tareas limitadas por la red se benefician de él incluso en Python.

🚀 Lógica central de escaneo: probando endpoints para la vulnerabilidad

El corazón del script es el módulo de escaneo, que toma la lista de endpoints descubiertos (rutas) y verifica cada uno en busca de señales de la vulnerabilidad CVE-2025-29927. El proceso para cada endpoint será:

• 1. Solicitud base (baseline): Enviar una solicitud HTTP GET al endpoint sin el encabezado especial, simulando una solicitud normal de usuario. Registrar el código de estado y la longitud del cuerpo de la respuesta (o un hash del cuerpo) para comparar. También anotar cualquier encabezado de respuesta interesante. En particular, si la respuesta contiene alguno de los encabezados de middleware de Next.js como x-middleware-rewrite, x-middleware-next o x-middleware-redirect, eso sugiere que esta ruta está protegida por middleware. También comprobamos si el estado no es 200 (lo que significa que el acceso fue denegado o redirigido), ya que esos son los que probablemente se puedan eludir. (Si el estado ya es 200 y el contenido se carga normalmente, es una página pública o la vulnerabilidad no aplica; podríamos probarla de todos modos, pero el interés real está en las páginas protegidas).
• 2. Crear solicitudes maliciosas: Enviar solicitudes adicionales al mismo endpoint, esta vez incluyendo el encabezado X-Middleware-Subrequest. Probaremos una variedad de valores de encabezado para asegurar la detección en todas las versiones de Next.js:

• Un valor genérico como "1" o "true" (algunas fuentes implican que simplemente establecer el encabezado a cualquier valor activa la omisión).

• El payload específico usado en exploits públicos, por ejemplo "middleware:middleware:middleware:middleware:middleware" (five repetitions of "middleware"). Se sabe que esto induce la omisión en las versiones más recientes (13+). Incluiremos exactamente este valor.

• El payload alternativo para proyectos que usan el directorio /src, por ejemplo "src/middleware:src/middleware:src/middleware:src/middleware:src/middleware"

• Opcionalmente, valores de un solo segmento como "middleware" o "src/middleware" por completitud (las versiones antiguas de Next.js podrían usar un archivo _middleware en el directorio pages, con un payload necesario ligeramente diferente, pero los payloads de múltiples segmentos anteriores cubren en gran medida los casos conocidos).

Cada una de estas solicitudes se realizará con el encabezado personalizado establecido. También nos aseguramos de usar el mismo método (GET) e incluir cualquier encabezado de la línea base que pudiera ser necesario (como cookies o tokens de autenticación si el usuario proporcionó alguno para un escaneo con sesión iniciada, aunque normalmente escaneamos sin autenticación).

• 3. Comparar respuestas: Para cada prueba de encabezado, comparar la respuesta con la línea base:

• Si la línea base fue un error o una redirección (por ejemplo, 401 No autorizado, 403 Prohibido, o una redirección al inicio de sesión) y una de las respuestas con el encabezado inyectado es 200 OK con un cuerpo significativamente más grande (o que indique de otra manera que la página se cargó), eso es un fuerte indicador de vulnerabilidad. Por ejemplo, si /admin devolviera 403 normalmente, pero con el encabezado devuelve 200 y contiene el HTML del panel de administración, lo marcamos.

• En algunos casos, la diferencia podría ser un 302 frente a un 200, o un 404 frente a un 200. Consideraremos un cambio de código de estado de no-200 a 200 como una señal probable. Además, si el estado permanece en 200 pero la longitud del contenido cambia drásticamente, eso podría indicar que el encabezado alteró el comportamiento (menos común para este fallo en particular, pero una posibilidad si la página normalmente entregaba una cosa y con el encabezado entregaba otra).

• Implementaremos comprobaciones como: if base_status_code != 200 and test_status_code == 200: (y quizás también asegurar test_body_length > base_body_length o que contenga alguna palabra clave de autenticación) y luego marcar como vulnerable. Si la línea base fue una redirección (por ejemplo, 307 a /login) y la prueba devuelve 200, también marcar. En esencia, “¿el acceso estaba antes denegado pero ahora permitido?”.

• Si el estado de la respuesta con el encabezado es 404 o 500 cuando la línea base fue una redirección, esto podría ser el escenario de envenenamiento de caché (omitir la redirección del middleware causando un 404 en el origen). Ese escenario es un poco más difícil de detectar con una sola solicitud, pero la presencia de un 404 con el encabezado cuando la línea base fue una redirección también podría notarse (aunque no es una omisión de autenticación, sigue siendo un efecto de la vulnerabilidad). Sin embargo, nuestro enfoque está en detectar una omisión de autenticación (acceso 200 OK).

• 4. Registro de resultados: Para cada endpoint probado, el script registrará el resultado. Si no se encuentra ninguna diferencia (no vulnerable), podemos mantenerlo en un registro verbose o descartarlo. Si se encuentra una posible vulnerabilidad, registramos el endpoint, el estado de la línea base y qué valor de encabezado causó un 200, etc. Estos se imprimirán en la consola y se guardarán en results.txt si el usuario optó por guardar los resultados. Deberíamos formatear esto claramente, por ejemplo:

• [*] /admin -> baseline 403, with X-Middleware-Subrequest (payload X) got 200 [VULNERABLE]

• También podemos imprimir algo como la longitud de la respuesta o un fragmento de la respuesta para confirmar (quizás solo la longitud por brevedad, por ejemplo, "len: 0 -> 10240 bytes"). Si se probaron múltiples payloads, podríamos listar cuáles tuvieron éxito.

• Si el sitio parece no ser una aplicación Next.js en absoluto (por ejemplo, no encontramos ningún /_next/static/ en la página de inicio, que es una señal reveladora), podríamos mostrar una nota: “No se encontraron indicadores de Next.js, el objetivo podría no estar usando Next.js – probablemente no sea vulnerable”. Pero aún podemos proceder de forma genérica, ya que la verificación de Next.js es una optimización más que una necesidad.Esta lógica estará encapsulada limpiamente. Por ejemplo, podríamos tener una función scan_endpoint(url, session, header_payloads) que devuelva un objeto de resultado o dict con si es vulnerable y detalles. Incorporaremos comprobaciones robustas para evitar falsos positivos. Específicamente, exigir un cambio de código de estado a 200 (u otra evidencia clara) ayuda a garantizar que solo marquemos bypass reales. Como se señala en el análisis de ProjectDiscovery, el escáner comprueba que la respuesta tenga código de estado 200 cuando se incluye el encabezado especial para confirmar la vulnerabilidad​.

🚀 Formato de Salida y Reporte

La salida del script debe ser fácil de leer e interpretar, además de poder guardarse opcionalmente en un archivo. Formatearemos la salida de consola con encabezados claros e indentación donde corresponda. Algunas consideraciones:

• Después del escaneo, imprime un resumen de los hallazgos. Por ejemplo: “Escaneo completo: 3 endpoints vulnerables encontrados (de 45 probados).” Luego lista los endpoints vulnerables con detalles.

• Usa un formato consistente para cada línea de resultado, como se mostró arriba, posiblemente con etiquetas [VULNERABLE] para llamar la atención. Si se usa una librería como rich, incluso podríamos codificar por colores “VULNERABLE” en rojo o amarillo. Incluso sin librerías adicionales, podemos usar códigos ANSI mediante colorama para resaltar, o simplemente texto en mayúsculas.

• Si no se encuentran vulnerabilidades, dilo explícitamente: “No se detectaron vulnerabilidades para CVE-2025-29927.”

• Si los resultados se van a guardar, asegúrate de que se escriban en un formato similar al del archivo. Posiblemente de una manera un poco más detallada o en CSV para uso programático, pero como el usuario mencionó específicamente un archivo de texto, probablemente simplemente escribiremos las mismas líneas en results.txt.

• Además, cualquier error crítico o excepción encontrada (como no poder cargar cierta página) puede reportarse en la salida de manera elegante (en lugar de un stack trace). Podemos capturar excepciones e imprimir una advertencia de una línea por cada URL fallida: p. ej., “Tiempo de espera agotado al cargar /blog (omitido)”. De esta manera, el usuario sabe si algunas rutas no fueron probadas.

Durante la ejecución, podríamos mostrar un spinner o progreso (para ejecuciones largas) o al menos imprimir qué página se está rastreando o qué endpoint se está probando, si el modo verbose está activado. Para una salida más limpia, podríamos mostrar solo los casos vulnerables descubiertos al final, pero un registro continuo (quizás escribiendo en un archivo de log separado) puede ayudar con la transparencia.

Dado el énfasis en un formato claro, usar viñetas o un diseño de tabla podría ayudar al imprimir múltiples resultados:

• Podríamos tabular como: Endpoint | Base Status | Base Length | Bypass Status | Bypass Length | HeaderValueUsed | Result

• Sin embargo, una forma de oración simple podría ser más legible para una amplia gama de usuarios. Nos aseguraremos de que cada resultado esté en una nueva línea y etiquetado claramente.

Al proporcionar tanto salida en pantalla como un guardado opcional en archivo, la herramienta es útil tanto para uso interactivo como para escaneo automatizado (donde el usuario puede revisar el archivo posteriormente o integrarlo en informes).

🚀 Estructura de Código Modular y Mejores Prácticas

Para hacer que el script sea mantenible y de nivel profesional, organizaremos el código en módulos, cada uno manejando un aspecto distinto de la funcionalidad. Una posible estructura de proyecto:

• crawler.py: Contiene la lógica de rastreo usando Playwright. Tendrá funciones como crawl_site(start_url, config) -> List[str] que devuelve una lista de rutas internas descubiertas. Este módulo manejará el lanzamiento del navegador, la obtención de páginas, la extracción de enlaces y la aplicación de filtros (dominio, exclusión de archivos estáticos). También podría albergar lógica auxiliar para normalizar URLs (p. ej., eliminar fragmentos de URL, manejar rutas relativas mediante urllib.parse.urljoin).

• scanner.py: Contiene la lógica de escaneo de la vulnerabilidad. Incluirá funciones como scan_paths(url_list, config) -> List[ScanResult]. Esto gestionará la creación de peticiones HTTP (usando requests.Session o un cliente httpx), la aplicación de encabezados, la comparación de respuestas y la recopilación de resultados. Si se usa multihilo, este módulo crearía el ThreadPool y gestionaría las tareas. Podría definir una pequeña clase de datos ScanResult para contener información sobre cada ruta (path, vulnerable: bool, details).

• config.py (o settings.py): Contiene el código para el menú de usuario y la configuración. Por ejemplo, una función get_user_config() que interactúa con el usuario y devuelve un objeto/diccionario de configuración con todos los ajustes elegidos (user_agent, timeout, proxy, flag output_file, etc.). Si se usan argumentos de CLI, este módulo podría alternativamente analizar argparse.ArgumentParser. En esencia, esta parte aísla toda la entrada del usuario y el manejo de configuración.

• utils.py: Funciones de utilidad, p. ej., para imprimir banners, formatear cadenas de salida, manejar salida con colores, o un helper común como is_static_resource(url) (para comprobar si una URL probablemente apunta a un archivo estático). También podría incluir una función para apagado elegante (para ser llamada en SIGINT).

• main.py: El script de punto de entrada que une todo. Hará lo siguiente:

• 1. Parsear o recopilar la configuración del usuario (usando config.py).
• 2. Llamar al rastreador para obtener la lista de endpoints.
• 3. Llamar al escáner para probar esos endpoints.
• 4. Recibir los resultados y mostrarlos en el formato solicitado.
• 5. Asegurar cualquier limpieza (cerrar el navegador, cerrar archivos, etc.). Si se distribuye como un script único, main podría simplemente estar al final de un solo archivo, pero por limpieza, separar es mejor.

Cada módulo estará diseñado para ser modular y reutilizable. Por ejemplo, uno podría reutilizar crawler.py para obtener enlaces del sitio para otros propósitos, o reutilizar scanner.py para probar esta vulnerabilidad en una lista dada de URLs (incluso sin rastreo).

Manejo de Excepciones y Apagado Elegante: Implementaremos un manejo robusto de excepciones:

• Rodea las operaciones de red con try/except (captura timeouts, errores de conexión, etc.). Si el rastreo de una página falla, regístralo y continúa con las demás. Si una petición de escaneo falla (p. ej., error de proxy), marca ese endpoint como error pero continúa escaneando el resto.

• Usa bloques finally o administradores de contexto para asegurar que los recursos se limpien. Por ejemplo, usa el contexto async_playwright() o asegúrate de que se llame a browser.close() al final del rastreo. De manera similar, asegúrate de que los manejadores de archivo se cierren después de escribir.

• Maneja KeyboardInterrupt (Ctrl+C): Podemos capturar el KeyboardInterrupt en el bucle principal e iniciar un apagado elegante – p. ej., imprimir “Deteniendo, limpiando…”, apagar los hilos (quizás usando ThreadPoolExecutor.shutdown(wait=False) para detener el lanzamiento de nuevas tareas) y cerrar el navegador. Esto previene procesos huérfanos o archivos bloqueados si el usuario aborta.

• Usa logging para mensajes de depuración (quizás mediante la librería logging de Python). En una herramienta profesional, tendrías niveles de logging; p. ej., los logs de depuración podrían incluir cada petición realizada, mientras que el nivel info solo muestra progreso de alto nivel. El usuario podría establecer un flag verbose para alternar esto. Por defecto, podríamos registrar información mínima para no abrumar la salida.

Calidad del Código: Nos adheriremos a las mejores prácticas de codificación:

• Seguir las guías de estilo PEP8 para la legibilidad.

• Usar nombres significativos para funciones y variables.

• Añadir docstrings a las funciones explicando su propósito y uso.

• Usar type hints en las firmas de funciones (anotaciones de tipo de Python 3) para hacer el código más fácil de entender y detectar problemas de tipo temprano.

• Modularizar constantes (como la lista de payloads de encabezado, listas de extensiones de archivos estáticos a ignorar, etc.) en la parte superior o en una configuración, para que puedan actualizarse fácilmente. Por ejemplo, HEADER_PAYLOADS = ["middleware:middleware:...","src/middleware:..."] etc., definidas en un solo lugar.

• Posiblemente incluir pruebas unitarias para algunas funciones auxiliares (si esto fuera un proyecto más grande, aunque para una herramienta de un solo script podría omitirse; aun así, diseñar pensando en la capacidad de prueba es beneficioso).

Mejoras de Nivel Profesional: Para hacer que el script sea más robusto y listo para producción, podemos considerar además:

• Soporte de autenticación: Permitir que el usuario proporcione cookies o credenciales si quiere escanear una sección autenticada del sitio (aunque la vulnerabilidad trata sobre evadir la autenticación, puede haber escenarios donde necesites iniciar sesión primero para alcanzar ciertos enlaces y luego probar la evasión en ellos – aunque el bypass presumiblemente funciona sin autenticación válida, esto podría ayudar a rastrear enlaces profundos que no son públicos).

• Archivo de configuración: En lugar de (o además de) la entrada interactiva, permitir leer opciones desde un archivo de configuración o variables de entorno, lo cual es útil para despliegues automatizados del escáner.

• Formatos de salida: Proporcionar salida en múltiples formatos como JSON o CSV para integración con otras herramientas. Por ejemplo, un flag --json podría volcar los resultados como JSON legible por máquina.

• Integración con frameworks existentes: La lógica podría integrarse en un framework de escaneo más grande (por ejemplo, convirtiéndola en un módulo para OWASP ZAP o integrándola con Nuclei de ProjectDiscovery generando un informe compatible). Como mínimo, asegurarse de que la salida del script identifique claramente la vulnerabilidad y las URLs afectadas para que pueda usarse en informes.

• Sesiones de navegador en paralelo: Si se apuntan aplicaciones muy grandes, considera lanzar múltiples contextos de navegador en paralelo para rastrear diferentes secciones de forma concurrente. Playwright puede manejar múltiples contextos (cada contexto está aislado, similar a perfiles de navegador separados)​. Esto podría acelerar el rastreo significativamente a costa de un mayor uso de recursos.

• Degradación elegante: Si Playwright falla (digamos que el entorno carece de display o de una instalación adecuada), el script podría recurrir a un rastreo más simple basado en requests (que podría perder algunos enlaces pero es mejor que nada). Esto hace que la herramienta sea más robusta en varios entornos. De manera similar, si la concurrencia se establece demasiado alta y causa problemas, captura esos y sugiere al usuario reducir el número de hilos.

Siguiendo una estructura limpia y estas mejores prácticas, el script será más fácil de mantener y extender. Cada componente puede trabajarse de forma independiente – por ejemplo, mejorar la capacidad del rastreador para analizar navegación pesada en JavaScript, o actualizar el escáner con nuevas variaciones de payloads de encabezado si investigaciones futuras encuentran patrones de explotación adicionales.

En conclusión, este diseño describe un enfoque integral para detectar CVE-2025-29927 en aplicaciones web. Aprovecha un navegador headless para un rastreo profundo, multi-threading para un escaneo eficiente y prácticas de codificación robustas para la fiabilidad. Al comparar respuestas con y sin el encabezado especial, puede identificar de manera fiable endpoints vulnerables donde se está evadiendo el middleware de Next.js​. El resultado es una herramienta de nivel profesional que ayuda a ingenieros de seguridad y desarrolladores a encontrar y abordar rápidamente esta vulnerabilidad crítica en sus aplicaciones.