MCP Inspector's 9.4: a dev tool that runs commands should not listen on 0.0.0.0

MCP Inspector is the official debugger for MCP servers. You click around in a browser UI; it starts a local Node proxy; the proxy spawns an MCP server process according to your config. Before 0.14.1, there was no authentication between the UI and that proxy.

So anything that could reach the proxy port could make it run commands on your machine. CVE-2025-49596, CVSS 9.4.

The shape of the bug

The advisory is blunt: versions below 0.14.1 lack authentication between the Inspector client and proxy, allowing unauthenticated requests to launch MCP commands over stdio. In engineering terms, three facts stack up:

• the proxy listened on 0.0.0.0, not 127.0.0.1;
• its HTTP endpoints had no token and no origin check;
• its job is literally “execute an MCP server”, and an MCP server is an arbitrary local command.

None of those is fatal alone. Together they are remote code execution. The attacker does not need to compromise your machine first — a malicious page only needs your browser to send a request to localhost, which is exactly what DNS rebinding does: resolve a domain to 127.0.0.1, let the browser treat it as a normal cross-origin request, and the proxy accepts it as legitimate.

“It’s a local tool” is the problem

Threat models for developer tooling often assume “only the developer is using it”, so authentication, bind addresses and CSRF protection get skipped. But the browser is a shared execution environment:

• you keep Inspector open while debugging and open some random page in another tab — that page can now talk to your localhost;
• on a corporate network, binding 0.0.0.0 means anyone on the same subnet can connect;
• on a CI box or remote dev machine, the exposure is wider still.

The “local proxy plus browser UI” pattern will only spread in the MCP ecosystem, because the debugging experience is genuinely good. But an endpoint that executes commands does not get to skip authentication because it runs on localhost.

Fixing it

Upstream added authentication in 0.14.1. On the deployment side, three things are worth doing anyway:

1. Bind to loopback. Listen on 127.0.0.1, never 0.0.0.0 for convenience;
2. Upgrade to 0.14.1 or later, and make sure npx pulls the new version rather than a cached one;
3. Treat Inspector as a privileged tool: start it when needed, close it after; do not leave it running in the background, and never on a host reachable from the internet.

The judgement

MCP made “the model can call tools” a default capability, and with it came a new class of attack surface: tool descriptions can be poisoned, and the channel that executes tools can be abused. This hole is fixed by a version bump, but the reminder outlives the patch: anything that pairs a browser UI with local execution should be designed as if it were remote code execution.

Cover image: MCP Inspector repository (GitHub).