Anthropic MCP Inspector Proxy Missing Auth Browser-Driven RCE - CVE-2025-49596

MCP Inspector is the debugging tool many developers run locally to exercise an MCP server during development. In mid-2025, Tenable Research (Rémy Marot) was credited with disclosing CVE-2025-49596 - tracked as GHSA-7f8r-222p-6f5g - a remote code execution flaw in MCP Inspector with a CVSS score of 9.4, exploitable by a website the developer merely visits. This advisory covers what was disclosed, why it lands on the agentic-endpoint layer rather than on your network or EDR, and how Anomity inventories and governs the MCP launch path that the flaw abuses.

What happened

MCP Inspector runs a proxy that the browser-based client uses to talk to MCP servers. In versions below 0.14.1, that proxy accepted arbitrary STDIO commands from its browser client without authenticating the request or validating where it came from. As a result, unauthenticated requests could launch MCP commands over STDIO on the host running Inspector. Because Inspector is the common local debugging setup, the precondition was simply that a developer had it running.

Security researchers showed how to turn that missing authentication into a drive-by attack. The chain adds the browser 0.0.0.0-day behavior - some browsers treat the address 0.0.0.0 as localhost, so a remote page's script can reach a locally bound service - and a CSRF weakness that let an unauthorized site issue requests the proxy accepted. Combined, a developer who visited a malicious website while Inspector was running could have arbitrary commands executed on their machine. The attack needs no credentials and targets the everyday case of a developer running Inspector locally.

The fix shipped in MCP Inspector 0.14.1. It auto-generates a session token that must accompany every proxy request, so an unauthenticated page can no longer drive STDIO commands, and it adds allowed-origin checks that reject traffic from unauthorized websites when the proxy is bound to localhost. This 2025 disclosure became the template for the 2026 wave of MCP-tooling RCE reports - the same shape recurs in the Anthropic MCP STDIO by-design execution class, where an MCP launch path trusts a source it should not.

Why this is an agentic-endpoint risk

MCP Inspector is not a server in production - it is a developer tool that spawns MCP servers over STDIO on a workstation. That distinction is exactly why this exposure is hard to see from the controls you already run. The proxy binds to localhost, so the network sees nothing crossing a perimeter. The spawned process looks like ordinary developer activity to EDR. DLP sees nothing at rest. The vulnerable artifact is an MCP tool installed bottom-up by an engineer to unblock a task, reporting to no security tool - one of the eight AI artifact types that make AI agents and MCP servers the new shadow IT.

The risk also illustrates the broader pattern: MCP tooling launches code over STDIO, and any tool in that path that mis-trusts a request source converts into host code execution. The question for a security team is not whether Inspector behaves as documented in 0.14.1 - it does once patched. It is which endpoints across the fleet are running an MCP launcher below a fixed version, and which agents can reach the local proxy at all. You cannot answer either without an inventory of the artifact layer, which is where this exposure lives and where fleet visibility starts.

How Anomity surfaces and governs it

Anomity treats the MCP launch path as an execution boundary and works the problem in three steps: inventory the artifact, decide at the hook, and keep the record.

First, inventory. Anomity inventories every MCP server, CLI, and related artifact on every managed endpoint as part of the eight AI artifact types it tracks, capturing the configuration metadata - including the MCP launchers a developer installs and the agent that drives them. It classifies each by trust signals and infers the capabilities it grants, so an Inspector instance below 0.14.1 surfaces as an unvetted artifact rather than going unnoticed on a workstation. Metadata only: secrets are redacted on the endpoint before anything leaves it.

Second, decide at the hook. On agents that expose a hook - for example, the PreToolUse event in Claude Code - Anomity evaluates each tool call and process spawn against your policy and returns allow, deny, or log before the call runs. A spawn that an unauthenticated local proxy tries to drive can be denied at the boundary instead of executing. That is the control runtime governance is built to provide, and it holds even in the window before a developer upgrades to a fixed version.

Third, keep the record. Every decision, and every added, changed, or removed MCP artifact, lands in a queryable 90-day audit trail, and decisions route to SIEM, Slack, email, or Jira. When a CVE in this class is published against tooling you run, you can answer where it is, what it was allowed to do, and what it did - from a record, not a guess. Anomity complements your Network, EDR, DLP, and GRC tooling; it covers the artifact layer those tools were never built to inventory.

You can't govern what you can't see.The Anomity principle

What to check across your fleet

• Inventory every endpoint running MCP Inspector and record its version; treat anything below 0.14.1 as exposed and upgrade it.
• Confirm that upgraded Inspectors enforce the auto-generated session token and the allowed-origin checks that 0.14.1 introduced.
• Identify any locally bound MCP proxy or launcher reachable by a browser, and account for the 0.0.0.0-day and CSRF path that turns a visited webpage into a request source.
• Map which agents and developer tools can spawn MCP servers over STDIO on a workstation, since that is the path CVE-2025-49596 abuses.
• Confirm that high-risk tool calls and process spawns are evaluated at the agent hook with allow/deny/log, so an untrusted local request is stopped before it runs.
• Verify that every spawn and every artifact change is written to a 90-day audit trail and routed to your SIEM, so you can scope the next MCP-tooling CVE quickly.

CVE-2025-49596 is patched in MCP Inspector 0.14.1, but the pattern it set - an MCP launch path that trusts a request source it should not - is what the 2026 reports keep repeating. The durable defense is to inventory every MCP artifact, govern spawns at the hook, and keep a record you can query. For the full attack surface, trust tiers, and the CVE wave this disclosure templated, see the pillar guide on MCP server security. To see Anomity inventory and govern the MCP layer across your fleet, request early access.