CVE-2026-23744: One HTTP Request, Total Host Takeover — Critical MCPJam Inspector Remote Code Execution

Aegiron 14 mins0

CVE: CVE-2026-23744
CVSS v3.1 Base Score: 9.8 (Critical) — Network exploitable, low complexity, no privileges required.
Severity: Critical
Exploitability: Very high — unauthenticated HTTP endpoint, default listens broadly.
Exploit availability: Public proof-of-concept exists.

Official patch / upgrade: https://github.com/modelcontextprotocol/inspector/releases/tag/v1.4.3

Quick summary

MCPJam’s inspector exposes an HTTP API that — when given a JSON payload — will launch arbitrary programs on the host. The API accepts a serverConfig object with a command and args and passes those straight to the process launcher with no authentication or validation. Because the inspector commonly listens on a network interface that’s reachable (default ports are used by the tool), a remote attacker can send a specially crafted POST and cause the host to execute any command the OS will run. That’s remote code execution (RCE) — full stop. Patch to the fixed version immediately.

Why this is bad

  • The component is meant for local developer testing, but it accepts network requests and will run whatever you tell it to run.
  • There is no authentication or sanity checks around the fields that become commands.
  • If the host is reachable from an attacker (local network, misconfigured cloud instance, port-forwarded machine), a single HTTP POST is enough to run arbitrary code as the user running inspector.
  • Attackers can use this to install backdoors, steal credentials, pivot, or destroy systems.

Technical breakdown

  1. The inspector exposes an HTTP endpoint used to install/connect to an MCP server. That endpoint expects JSON with a serverConfig that contains command (string) and args (array).
  2. The inspector code takes those fields and invokes the OS process launcher (e.g., exec/spawn in Node), passing command and args verbatim. There’s no allowlist, no escaping, no authentication.
  3. The inspector often listens on an address bound to all interfaces by default (so it’s reachable from outside localhost unless the operator changed that).
  4. An attacker issues a POST to the endpoint (example payload below) and causes the inspector to run arbitrary commands. Those commands execute with whatever privileges the inspector process has — usually the user account of the developer or service that started it.

Example PoC (educational)

This is the canonical minimal example used to demonstrate the issue in a lab:

POST /api/mcp/connect HTTP/1.1
Host: <target>:6274
Content-Type: application/json

{
  "serverConfig": {
    "command":"cmd.exe",
    "args":["/c","calc"],
    "env": {}
  },
  "serverId":"poc"
}

On Linux you can substitute "/bin/sh", ["-c", "<payload>"] to execute shell commands (for example, a reverse shell) — but only ever in a controlled lab.

Attack chain

  1. Discovery: scan networks for hosts with the inspector port(s) open.
  2. Exploit: POST to /api/mcp/connect with serverConfig.command and args crafted to run their payload (reverse shell, downloader, etc.).
  3. Execute: arbitrary code runs under the inspector process user.
  4. Post-exploit: persist, gather secrets, move laterally.

Because the API is unauthenticated and exposed by default, an attacker only needs network reachability.

Practical mitigation

  1. Patch immediately. Upgrade to the fixed release (see the official patch link at the top).
  2. If you cannot patch immediately:
    • Block the inspector ports at the network/firewall level (default UI port and proxy port used by inspector), or restrict access to trusted IPs only.
    • Rebind the inspector to localhost (127.0.0.1) so it does not accept external connections.
  3. Harden runtime: run inspector under a non-privileged account, in a sandbox or container, and avoid running on critical production hosts.
  4. Rotate credentials if you suspect the host may have been abused (API keys, tokens, SSH keys, cloud credentials).
  5. Monitor and hunt (see detection section).

How to detect exploitation

Core idea

Detect HTTP POSTs to the inspector’s /api/mcp/connect endpoint that include serverConfig with command/args, and correlate those requests to process creation events where the parent is the inspector or the user running it. Also hunt for uncommon shells or child processes that shouldn’t be spawned in your environment.

Easy file/log searches

  • Search web or proxy logs for requests to /api/mcp/connect, especially POSTs whose bodies include serverConfig, command, or args.
  • On endpoints, search process creation logs for shells (cmd.exe, powershell.exe, /bin/sh, /bin/bash) launched by the inspector process or by the user who runs it.
  • Look for sudden execution of network tooling (e.g., curl, wget, nc) near the time of any /api/mcp/connect POST.

Examples (replace index/sourcetype with your environment):

Web/proxy:

index=web_access uri="/api/mcp/connect" | search _raw="serverConfig" OR _raw="\"command\""

Endpoint (Sysmon-like events):

index=endpoint EventID=1 Image="*\\cmd.exe" ParentImage="*\\inspector*" OR ParentCommandLine="*inspector*"

Suricata rule(s)

Place these into your Suricata ruleset and tune sid and rev for your environment. The first rule triggers on an HTTP POST to the connect endpoint with JSON indicators. The second rule is broader and flags HTTP POSTs with serverConfig anywhere (useful if the endpoint path is customized).

Rule 1 — endpoint-specific

alert http any any -> any any (msg:"MCPJam inspector suspicious /api/mcp/connect POST containing serverConfig - possible RCE attempt"; flow:to_server,established; http.method; content:"POST"; http.uri; startswith:"/api/mcp/connect"; http.client_body; content:"serverConfig"; http_client_body; content:"command"; http_client_body; content:"args"; sid:1001001; rev:1; classtype:attempted-admin;)

Rule 2 — generic JSON indicator

alert http any any -> any any (msg:"MCPJam inspector suspicious POST containing serverConfig - possible RCE"; flow:to_server,established; http.method; content:"POST"; http.client_body; content:"serverConfig"; http_client_body; content:"command"; http_client_body; content:"args"; sid:1001002; rev:1; classtype:attempted-admin;)

Notes on tuning and false positives

  • These rules search the HTTP body for JSON keys. If your environment legitimately posts serverConfig to an internal inspector, you will get hits — tune by restricting source/destination IPs or by adding http.host matches for known hostnames.
  • If your Suricata is inline with encrypted HTTPS, make sure you have an HTTPS inspection point (or use proxy logs) where bodies are visible.
  • Consider adding a follow-up rule that looks for suspicious child processes following such a POST (e.g., process creation logs showing shells), and escalate only when both network and host signals line up.

Host-level detection recipes

  • Sysmon / EDR detection: alert on ProcessCreate where ParentImage is the inspector binary and Image is a shell or a downloader (cmd.exe, powershell.exe, /bin/sh, curl, wget, nc).
  • auditd (Linux): monitor execve calls where the parent process is the inspector process PID and the command line contains suspicious sequences (e.g., -c, bash -i, reverse shell patterns).
  • File system: watch for new executable files written to /tmp, /var/tmp, or user home directories immediately after a detected POST.
  • Network: look for outgoing connections to unfamiliar IPs or long-lived reverse shell sessions shortly after an /api/mcp/connect POST.

Indicators of compromise (IoCs) to hunt for

  • Any POST to /api/mcp/connect with JSON containing serverConfig, command, or args.
  • Process tree: inspector -> shell (cmd/powershell/sh/bash).
  • Unexpected downloads/executions immediately after such POSTs.
  • New users, scheduled tasks, services, or persistence artifacts appearing after a POST.

Forensics and incident response

  1. Isolate the host from the network and preserve volatile data (memory, running processes).
  2. Collect process lists, command-line arguments, and parent/child relationships.
  3. Capture web server/proxy logs and full request bodies for any /api/mcp/connect POSTs.
  4. Collect network captures (PCAP) covering the suspected timeframe.
  5. Look for lateral movement (new SSH connections, cloud console tokens, unusual API calls).
  6. When cleaning: remove any persistence, rotate credentials that were present on the host, and rebuild hosts if unsure about compromise depth.

Practical hunting query examples

  • Web logs (grep-like):
grep -i "\"serverConfig\"" /var/log/nginx/*access* /var/log/httpd/*access*
  • Sysmon (Windows) — find suspicious children of inspector:
EventID=1 | where ParentImage like "%inspector%" and (Image like "%\\cmd.exe" or Image like "%\\powershell.exe%")
  • Linux process accounting — list recent execs by the inspector user:
ausearch -ua inspector_user | aureport --summary

Final takeaway

  • If you run inspector anywhere: upgrade to the fixed release now.
  • If you cannot upgrade immediately: firewall the inspector ports, rebind to localhost, and run the inspector only in isolated developer environments.
  • Hunt your logs for /api/mcp/connect POSTs and suspicious process creation; collect artifacts if you find anything.
  • Rotate keys/secrets from affected hosts if there’s any evidence of unusual activity.

Aegiron

Backed by 11+ years in cybersecurity and incident response, we decode the latest threats shaping today’s digital battlefield. This blog cuts through the noise with clear insights on vulnerabilities, emerging exploits, and the cyber news defenders can’t afford to miss.