MCP Inspector Vulnerability: Three New RCE Advisories

The MCP Inspector vulnerability story just escalated from one tool to the reference tool. On October 21, three security advisories were published against @modelcontextprotocol/inspector, the official debugging utility that developers point at MCP servers to see what those servers do. All three let a malicious remote MCP server run commands on the developer's machine, and they arrive one week after Pillar Security's opencode disclosure showed the same flaw shape in a different client. The uncomfortable part is the target: Inspector exists to inspect servers you do not trust, so the people running it are, by design, the people most exposed to a hostile server. This post walks through each advisory, the affected versions and fixes, and the pattern developers should take from it. Source Source Source

Why Inspector is the worst tool to have a bug in

MCP Inspector is the Model Context Protocol project's own debugging UI: you run it locally, point it at an MCP server, and it shows the server's tools, resources and behavior. Its entire purpose is to be pointed at servers whose behavior is unknown, as one of the new advisories puts it, which means its normal use case is contact with untrusted input. It also runs with the developer's privileges on the developer's machine, next to SSH keys, cloud credentials and source code. A remote code execution flaw here is not a theoretical supply chain concern; it is a direct path from "I wanted to check what this MCP server does" to a compromised workstation. Source

Advisory one: OAuth callback switches transport to stdio

The most severe of the three, rated Critical, is GHSA-4fc4-wcmh-4g86. A malicious remote MCP server answers Inspector's connection attempt with an OAuth challenge and points it at an attacker-controlled authorization server. After the developer authorizes, the attacker redirects the browser back to Inspector's callback URL with extra configuration parameters appended: transport set to stdio, plus a serverCommand and serverArgs of the attacker's choosing. Inspector's callback page initialized its connection state directly from the URL query string, so the attacker's parameters became the new connection settings, and a stdio connection with an arbitrary command is local code execution. The chain needs the developer to complete the OAuth sign-in, but nothing else: no tool approval, no model involvement. Affected versions are 0.13.0 through 1.0.2 of @modelcontextprotocol/inspector and inspector-client; the fix is 1.0.3. Source

Advisory two: PowerShell injection through the sign-in URL

GHSA-q978-78c7-phqw is the same attack shape as last week's opencode flaw, inside the official tooling. When a remote MCP server answers a connection with a 401 and serves OAuth discovery documents, the authorization_endpoint field is a free-form string the server chooses. On Windows and WSL, Inspector passed that URL to the npm open package, which placed it inside a PowerShell double-quoted string without escaping and executed it. PowerShell evaluates $( ) subexpressions inside double-quoted strings, and URL serialization preserves every character a payload needs, so a crafted authorization endpoint runs commands when Inspector opens the browser. The advisory notes a telling detail: five lines earlier in the same function, the application path was escaped, so the need to escape was understood and applied to one argument but not the other. macOS and Linux are not affected because the browser is opened without a shell. Rated High. Affected: Inspector 2.0.0 through 2.11.0; fixed in 2.12.0. Source

Advisory three: the MCP App sandbox leaks the proxy auth token

GHSA-6x67-4w4w-9f3w attacks Inspector's newer MCP App support. Inspector renders MCP Apps inside a sandbox that is served from the same local origin as its proxy server. The proxy has two defenses: an origin check against DNS rebinding, and an auth token required in a header. The origin check fails open for same-origin requests because browsers omit the Origin header entirely on those, so the sandboxed app sits inside the perimeter. From there, the advisory's chain escalates popup privileges through the client's own link-opening handler, reads the proxy auth token, and calls the proxy directly to launch arbitrary stdio commands. All three published packages are affected from 0.20.0 through 1.0.2: @modelcontextprotocol/inspector, inspector-client, and inspector-server. The fix is 1.0.3. Source

This is a pattern, not a bad week

The October 21 trio is not the first time Inspector itself has been the vulnerability. In June 2025, GHSA-7f8r-222p-6f5g (Critical, 9.4) allowed unauthenticated requests to the Inspector proxy to launch MCP commands over stdio because there was no authentication between client and proxy; Tenable's Rémy Marot was credited. In September 2025, GHSA-g9hg-qhmf-q45m (High, 8.6) showed an XSS issue when connecting to an untrusted server with a malicious redirect URI, exploitable into command execution. And outside Inspector, the opencode flaw disclosed by Pillar Security on October 19 used the same OAuth-authorization-URL-to-PowerShell chain, fixed in opencode 1.18.33 without a requested CVE or published advisory, so scanners that key on CVE records will not flag affected installs. We covered that one in our MCP OAuth security checklist. Source Source Source

The lesson generalizes: local developer tooling that brokers between your machine and remote AI infrastructure is production-grade attack surface with hobby-grade hardening expectations. The model is irrelevant in every one of these chains; the exploit lives in the plumbing: OAuth fields, URL handling, sandbox boundaries, proxy authentication. Source

What to do now

Upgrade first, then change habits. If you use MCP Inspector, go to 1.0.3 on the 1.x line or 2.12.0 on the 2.x line; check all three packages, including inspector-client and inspector-server, because the advisory ranges cover them separately. If you used opencode on Windows or WSL, make sure you are on 1.18.33 or later, and do not rely on your scanner to tell you, since no CVE exists. Source Source

Then treat inspection as a privileged operation. Point Inspector at unknown servers only from an environment that does not hold your real credentials: a disposable VM, a container, or at minimum a machine without cloud keys and SSH access. Be suspicious of OAuth sign-in flows that appear while merely connecting to a server, since sign-in is the trigger for two of the three new chains. And apply the same scrutiny to any new MCP server before adding it to a client config, because a server that is honest today can be compromised or resold tomorrow; our MCP server security best practices cover the standing review, and the AI agent security checklist covers the wider agent surface. Source