Is the MCP Inspector safe to run while I build an MCP server? Which version fixes CVE-2025-49596 and the advisories published since, and how should I run it?

What should I check, step by step?

1. Find every copy: run npm ls -g @modelcontextprotocol/inspector, check each project's node_modules and lockfile, and remember that npx can run a cached older version. Pin @modelcontextprotocol/inspector@2.14.0 or later (or @v1-latest, currently 1.0.4) instead of relying on whatever npx resolves.

2. v2 needs Node ^22.23.4, ^24.22.1 or >=26.12.1. If an old Node is what keeps you on an old Inspector, upgrade Node rather than staying on a vulnerable release.
3. Leave authentication on. Don't set DANGEROUSLY_OMIT_AUTH. One of the October advisories (GHSA-wmjf-2m46-2352) showed that with auth off, requests with no Origin header could reach process launch without any token.
4. Keep the default bind of 127.0.0.1. v2 refuses 0.0.0.0, :: or an empty HOST unless DANGEROUSLY_BIND_ALL_INTERFACES is set; don't set it on a laptop. In Docker, publish ports as -p 127.0.0.1:6274:6274, not -p 6274:6274.
5. Treat the API token like a password. It's printed in the launch banner and guards every /api route; if you set your own with MCP_INSPECTOR_API_TOKEN, use at least 32 random characters, and don't paste the banner URL into chats, tickets or screenshots.
6. Point the Inspector only at servers you'd be willing to run code from. CVE-2025-58444 and three of the October advisories start with the Inspector connecting to a malicious remote server or opening its OAuth flow, before you call a single tool.
7. Close the Inspector when you're done testing instead of leaving it running in a terminal while you browse. Several of these attacks only need you to visit a web page while it's up.
8. If you ran a vulnerable version and connected it to an unfamiliar server or browsed untrusted sites while it was running, check for unexpected processes and startup items and rotate tokens the Inspector stored. v2 keeps OAuth tokens and stdio env values in the OS keychain, or in ~/.mcp-inspector/secrets.json where there's no keychain.
9. Watch the advisories page (github.com/modelcontextprotocol/inspector/security/advisories) or enable Dependabot or npm audit alerts for the package, since fixes have arrived in batches.

Why can a bug in the MCP Inspector run commands on my machine?

The Inspector has a web UI and a local backend. To test a stdio MCP server, the backend starts the server as a child process from a command and arguments you give it. Anything that can send that backend a request with its token can choose the command. That's why every serious Inspector advisory has ended in the same place: getting a request, or the token, to the backend.

• Oligo Security, which reported CVE-2025-49596, noted that the Python SDK's quickstart command mcp dev starts the Inspector, so many developers ran it without choosing to.

What was MCP Inspector CVE-2025-49596 and how was it fixed?

Before 0.14.1, the Inspector's proxy accepted requests with no authentication. Oligo showed that a page on any website could send a request to http://0.0.0.0:6277/sse with transportType=stdio and a command of its choosing, because some browsers let public pages reach 0.0.0.0 (the "0.0.0.0-day" Oligo had reported in 2024), and that DNS rebinding worked too. Merely visiting the page while the Inspector ran was enough.

• GitHub's advisory GHSA-7f8r-222p-6f5g (published June 13, 2025, CVSS 4.0 score 9.4) credits Rémy Marot of Tenable; Oligo said Anthropic told it another researcher had reported the issue first, on March 26, 2025. Version 0.14.1 added a random session token required on proxy requests and an allow-list check on the Origin header.
• CVE-2025-58444 (GHSA-g9hg-qhmf-q45m, fixed in 0.16.6 in September 2025, CVSS 4.0 score 8.6) came from the other direction: a remote MCP server returned a crafted redirect URL during OAuth, the Inspector rendered it as script, and that script could talk to the local proxy. The fix validates redirect URL schemes.

What MCP Inspector security advisories were published in 2026?

On October 21, 2026 the project published nine advisories. Two are rated critical (CVSS 9.6): a malicious server's OAuth callback could append transport=stdio and a command to the Inspector's callback URL, which the UI read and then connected with (GHSA-4fc4-wcmh-4g86, affecting 0.13.0 to 1.0.2); and a remote MCP App running in the Inspector's sandbox could obtain the proxy token and launch commands (GHSA-6x67-4w4w-9f3w, 0.20.0 to 1.0.2). Both are fixed in 1.0.3.

• Two high-severity issues affected v2 up to 2.11.0 and are fixed in 2.12.0: on Windows and WSL, a server-chosen OAuth authorization URL was passed into PowerShell, where a $( ) subexpression ran (GHSA-q978-78c7-phqw), the same class of bug as mcp-remote's CVE-2025-6514; and the DNS-rebinding defence was incomplete because requests without an Origin header passed and there was no Host header check, letting a rebinding page read the API token and stored OAuth tokens (GHSA-vcc9-3xgm-p9v4). A third high, GHSA-wmjf-2m46-2352, covers the no-Origin bypass when auth was switched off in v1 (fixed in 1.0.3).
• The rest are medium or low: the /fetch proxy leaking Authorization and Cookie headers across cross-origin redirects, the session token leaking to a query-controlled origin, no size cap on proxied responses, and SSE auth headers written to logs. On November 5, 2026, 2.14.0 and 1.0.4 fixed three more medium issues: an MCP App escaping its Content Security Policy, unvalidated input in server.json import and the elicitation URL dialog, and a tool output schema regex that could stall the Inspector. None of these advisories had a CVE ID assigned when we checked on November 10, 2026.
• v2 also changed defaults in ways that help: it refuses an all-interfaces bind unless you opt in, checks the Host header (answering 403 for unknown hosts), and derives the Origin allow-list from the bind address. Those defaults only protect you if you leave them alone.