Connect to Inspect, Stay to Get Owned: Two Critical RCEs Turn MCP Inspector Against Its Operator

2026-11-01 Agent & Supply Chain Security by al-ice.ai Editorial

MCP Inspector is the tool you point at servers you do not trust yet. That is its entire job: connect to an unknown MCP server, poke at its tools, watch what comes back. In late October 2026, two critical 9.6 advisories published on the Inspector’s own repository showed that a hostile server can turn that workflow around — connecting the Inspector is enough for the server to run arbitrary commands on the operator’s machine, once through the OAuth callback and once through the MCP App sandbox. Both are fixed in 1.0.3. And here is the part that should alarm anyone running an audit queue: as of 1 November 2026, neither advisory exists in the GitHub Advisory Database or OSV, which means npm audit, Dependabot, and OSV-Scanner all report a pinned 1.0.2 install as clean. The reference debugging tool for the protocol had remote code execution, and the scanners were silent.

The callback that reinstalls your transport

GHSA-4fc4-wcmh-4g86 (affected 0.13.0 through 1.0.2, no CVE assigned) starts from a normal-looking flow. The operator connects to an attacker-controlled remote MCP server; the server answers with an OAuth challenge pointing at an attacker-controlled authorization server. After authorization, the attacker redirects the browser to the Inspector’s callback URL — and appends Inspector configuration parameters to it: transport=stdio&serverCommand=<any_command>&serverArgs=<any_param>. The callback page initializes its connection state straight from the URL query string — getInitialCommand(), getInitialArgs() and getInitialTransportType() all read window.location — while the OAuth handler extracts only the code and never strips the extra parameters. After the token exchange succeeds, the callback auto-reconnects, and because the page now believes it is a stdio session, it sends an authenticated request to the local /stdio proxy endpoint carrying the attacker’s command. The proxy starts it via StdioClientTransport. The OAuth dance completes, the tokens are valid, and a hostile binary is running on the analyst’s workstation. The advisory’s recommended fix is structural, not a denylist: the callback must parse only OAuth fields and recover the original connection parameters from storage instead of the URL.

The sandbox with a spare key

GHSA-6x67-4w4w-9f3w (affected 0.20.0 through 1.0.2, also CVE-less, reported by bhavya32 as was the callback flaw) takes the second road in. Inspector renders remote MCP App content inside a sandboxed frame served from the proxy port — and that sandbox can execute JavaScript. From there the chain is three short steps. First, the sandboxed app fires a ui/open-link postMessage that the client window honors by opening a popup. Second, the popup lands in the same browsing-context group, which shares the sessionStorage where the Inspector saved its MCP_PROXY_AUTH_TOKEN at startup — token exfiltrated. Third, the app calls the proxy’s stdio endpoint directly: the proxy’s origin check only rejects requests that carry a disallowed Origin header, and same-origin requests from the sandbox carry none at all, so the check passes silently and the auth token does the rest. Arbitrary local command execution, from a UI widget, with no transport switch required. Both advisories score CVSS 9.6 (network, low complexity, no privileges, scope changed) — the user-interaction bit is the only thing keeping them off 10.0, and “connect to a server to inspect it” is the interaction the tool exists for.

The database gap is the vulnerability

This belongs next to the recent silent OpenCode MCP OAuth RCE — same lesson, one layer up the stack. That flaw hid because the vendor shipped the fix without an advisory; these flaws hide despite advisories, because repository-published advisories do not reach the global databases automatically. We verified it directly on 1 November: api.github.com/advisories/GHSA-4fc4-wcmh-4g86 and GHSA-6x67-4w4w-9f3w both return 404, and an OSV query for @modelcontextprotocol/inspector@1.0.2 returns an empty set. An independent writeup on DEV Community flagged the same gap and published version-check guidance for pinned and npx installs. The same advisory batch carries a warning for the 2.x line too: GHSA-q978-78c7-phqw (High, 8.8, 2.0.0–2.11.0, fixed in 2.12.0) lets a remote server’s OAuth authorization URL reach PowerShell unescaped on Windows and WSL — the same URL-into-shell class as the Pillar OpenCode finding, now in the reference Inspector itself. Until the databases catch up, the only reliable inventory is manual: npm ls @modelcontextprotocol/inspector in every project, plus the global install, and version-pinned npx invocations.

What to do

Upgrade to 1.0.3 (1.x) or 2.12.0 (2.x) now. Do not wait for a Dependabot PR — none is coming until the advisories enter the global databases.
Pin Inspector versions in npx invocations. Unpinned npx @modelcontextprotocol/inspector and stale global installs are how a 1.0.2 keeps surviving in audit toolchains.
Connect only to servers you already trust, and stop the Inspector when done. Both critical chains fire during connection; the proxy (6277) and UI (6274) listeners should not be left running.
Never start it with DANGEROUSLY_OMIT_AUTH. Two further advisories in the same batch (High 7.5 token-adjacent, Medium 5.3 session-token leak) bite only — or bite hardest — in that mode.

Sources: