Published: 2026-10-27

MCP Inspector: nine security advisories, two critical — testing an untrusted server could take over your laptop

In short: on 21 October 2026 the MCP project published nine security advisories for MCP Inspector, the official MCP testing tool. Two are critical (CVSS 9.6): a malicious remote server could abuse the OAuth step to run arbitrary commands on the developer's machine. Fixed versions are 2.12.0 (current line) and 1.0.3 (deprecated v1 line). No CVE has been assigned yet.

MCP Inspector is what developers use to connect to an MCP server and try it out: call tools, inspect responses, walk through the OAuth sign-in. It runs locally, usually via npx @modelcontextprotocol/inspector, and starts a web UI plus a proxy on the developer's own machine. Because its whole purpose is to test servers whose behaviour you don't know yet, it is an attractive target. One of the advisories puts it plainly: the people who use this tool are, by design, the people most at risk.

What exactly was found?

The nine advisories appeared on GitHub on 21 October alongside two releases: 1.0.3 for the deprecated v1 line and 2.12.0 for the current v2 line (available since 28 July). GitHub rates two as critical, three high, three moderate and one low. The most serious:

OAuth callback switches to a local command (critical, 9.6; versions 0.13.0 to 1.0.2). A malicious remote server sends the user through its own authorization server and back to Inspector's callback with extra URL parameters. Inspector read the transport type and launch command from those parameters and then reconnected automatically, this time over stdio: the attacker's command ran locally.
MCP App steals the proxy token (critical, 9.6; 0.20.0 to 1.0.2). An interactive app UI served by a remote server runs in a sandbox on the same port as the proxy. Through a detour it could obtain the proxy's auth token and use it to launch a local command after all.
PowerShell injection via the authorization URL (high, 8.8; 2.0.0 to 2.11.0, Windows and WSL). Inspector automatically opens whatever OAuth URL the server provides. On Windows that URL went unescaped into a PowerShell command. According to the advisory this fires while connecting: no tool is called and nothing is approved.
DNS rebinding (high; 2.0.0 to 2.11.0). A malicious website could read Inspector's API token and stored OAuth tokens. The advisory calls this an incomplete fix for CVE-2025-49596, the critical Inspector flaw from June 2025.
Disabled authentication (high, 7.5; 0.14.1 to 1.0.2). Setting DANGEROUSLY_OMIT_AUTH also removed the second line of defence: requests without an Origin header still got through.

The remaining four concern leaked headers and tokens, memory exhaustion through the fetch proxy, and logging of authentication headers.

What changed in the fixes?

Version 1.0.3 no longer takes connection settings from the OAuth callback URL and never reconnects over stdio there. Links from MCP Apps only open as http(s), and the proxy rejects same-origin browser requests to its API. Version 2.12.0 only opens http(s) URLs, validates the Host header against an allow-list (new MCP_INSPECTOR_ALLOWED_HOSTS variable for reverse proxies) and caps fetch-proxy responses at 4 MiB. On npm, latest now points to 2.12.0 and v1-latest to 1.0.3.

Why does this matter to organisations, not just developers?

A developer laptop is rarely an ordinary workstation. It holds source code, cloud credentials, SSH keys and often access to internal systems. People who build or evaluate MCP servers use Inspector precisely to try unknown or third-party servers, for instance during vendor selection. A critical flaw in that tool is a direct path to some of the most privileged machines in the company. And Inspector rarely shows up in any software inventory: it is launched ad hoc via npx and then forgotten.

Our advice

(1) Always launch Inspector as npx @modelcontextprotocol/inspector@latest (≥ 2.12.0), or 1.0.3 if you must stay on v1. Search scripts, docs and package.json files for pinned older versions. (2) Don't test unknown remote servers on a machine holding production credentials; use a separate VM or container without access to internal networks. (3) Never enable DANGEROUSLY_OMIT_AUTH outside an isolated environment. (4) Include developer tools like Inspector in your inventory of MCP components and your patching policy. More in MCP security and building an MCP server.

What about the reference servers?

Four days later, on 25 October, eight advisories followed for the official reference servers, together with release v2.1.0. These are less severe: three moderate and five low. The most serious (6.5) concerns environment-variable exfiltration in server-everything; four relate to path checks and symlinks in server-filesystem. Two advisories bypass the private-address guard that fetch only gained in 2026.10.10, which we covered last week. Fixes: server-filesystem and server-everything 2.0.1, mcp-server-fetch 2026.10.24.

The bigger picture: after the advisories for the official SDKs in early October, the project's testing tool and example servers have now been scrutinised too. That is good news: researchers and maintainers are taking the core of the ecosystem seriously. It also means "official" does not mean "safe without updates".

Sources

Frequently asked questions

Which version of MCP Inspector is safe?

Version 2.12.0 or later on the current v2 line, or 1.0.3 on the deprecated v1 line. Both were released on 21 October 2026. Running npx @modelcontextprotocol/inspector@latest gets you the newest v2 release.

Do the MCP Inspector flaws have CVE IDs?

Not yet. The nine advisories are published as GitHub Security Advisories (GHSA); as of 26 October 2026 no CVE was linked. Use the GHSA IDs to track them.

Should I worry if I only use Inspector with my own servers?

Less so, but not zero. The critical flaws require connecting to a malicious server, but the DNS-rebinding flaw in v2 could be exploited by an ordinary malicious website while Inspector was running. Updating is sensible in every case.

Last updated: 2026-10-27