Inspecting the Inspector: RCE in MCP's Official Debugging Tool

Executive Summary

Background: Two weeks ago we published research called "Open and Shut: Remote Code Execution in opencode via MCP OAuth," detailing how a remote MCP server could run code on a developer's Windows or WSL machine during OAuth login in opencode. The exact same chain we demonstrated in opencode existed in the MCP Inspector.

What is MCP Inspector: The MCP Inspector is the official debugging and inspection developer tool maintained by the Model Context Protocol project. Developers use it to vet local and remote MCP servers they don't trust or still need to verify.

It's also widely used, with 11,000 stars and 768,000 weekly downloads. Amazon documents it for testing Amazon Bedrock AgentCore Gateway and its Knowledge MCP Server, Cloudflare recommends it for testing remote MCP servers on its platform, and Microsoft's Azure DevOps MCP server ships a dedicated Inspector launch script.

What we found: Pillar Security discovered a high severity remote code execution (RCE) vulnerability in the MCP Inspector affecting Windows and Windows Subsystem for Linux (WSL). The vulnerability allows an attacker-controlled remote MCP server to execute arbitrary code on a developer's machine during a remote MCP OAuth authentication process, without additional user interaction or consent.

We reported this finding to the Inspector maintainers, who accepted it as a vulnerability, shipped a fix in 2.12.0, and published GHSA-q978-78c7-phqw, rated High (CVSS 3.1 8.8). This vulnerability is also tracked as CVE-2026-119025, rated High (CVSS 4.0 7.7), which points to the root cause in the open package. The CVE's affected products list open, the MCP Inspector and opencode together, so scanners can now flag all three. The difference between the GHSA and CVE severities stems from the CVSS version.

What to do: On Windows or WSL, upgrade the Inspector to 2.12.0+, opencode to 1.18.33+, and any direct use of open to 11.0.0+.

Why the MCP Inspector finding matters

The Inspector exists to answer one question safely: what does this MCP server do? You point it at something you haven't vetted or verified, and it shows you the tools, resources and prompts before you trust it in a real agent. It's the tool where you're supposed to be able to look at a hostile server without getting hurt.

It didn't hold up. The Inspector fell over on the first thing an untrusted server sends, before it listed a single tool. A server-chosen authorization_endpoint in the OAuth handshake reached PowerShell, and the code ran before the browser even opened. Auto-open was on by default in an interactive terminal, so the person doing the inspecting never had to approve anything. The tool built to examine untrusted servers trusted one of them.

That is the real lesson.

Our opencode report left an open question: is a malicious remote MCP server a realistic attacker? Some teams treat configured servers like the user's own plugins, which puts a hostile server out of scope. The Inspector's own design contradicts that model. Its whole purpose assumes the server may be hostile, and the maintainers accepted the report as a vulnerability, shipped a fix and published an advisory.

When the MCP project treats "the server you connected to is hostile" as in scope for its own reference tooling, every client, coding agent and IDE integration that implements the same OAuth flow should read that as the default. A remote MCP server is an untrusted input. We're grateful the MCP Inspector maintainers put that on record.

The bug

The full walkthrough is in our first post. Short version:

1. A remote MCP server answers 401 with a WWW-Authenticate challenge.
2. Its OAuth discovery handshake names an authorization_endpoint, a free-form string the remote server chooses.
3. The client opens that URL automatically with the open package.
4. On Windows and WSL, open versions before 11.0.0 place the URL into a PowerShell double-quoted string, unescaped, and run it with -EncodedCommand.
5. PowerShell evaluates $(...) inside double quotes.

The payload is an ordinary, valid https input:

The code runs while you're connecting to the server.

In the Inspector, the chain ran through:

There were two more copies of the same call in the TUI and the web client, and auto-open was on by default in an interactive terminal.

The fix

The maintainers pushed the fix in two commits and released it in Inspector 2.12.0 on 2026-10-21:

• 094847a "bump open to v11 and restrict openUrl to http(s)": moves open from version 10.2.0 to 11.0.4, adds an overrides entry so the web client's copy can't stay on 10.x, and makes openUrl refuse anything that doesn't parse as http: or https:.
• f7e0377 "open the URL that was checked, not the raw input": closes a gap where the validated URL and the URL passed to open could differ.
• Merged in 73f3cf8.

A few notes worth taking from this:

The open dependency bump is the root cause fix. All three Inspector dependency manifests constrained open to the vulnerable 10.x release line. A routine npm update would therefore miss the fix in 11.x. The maintainers had to upgrade the dependency and add an override for the web client's transitive copy.

Scheme validation was added as defense in depth. Our payload is a valid HTTPS URL, so it passes an HTTP/HTTPS scheme check. What stops this payload is open@11 escaping the target and placing it in a single-quoted PowerShell string, where $(...) is treated as literal text.

The CVE that covers all affected products

The bug lives in how downstream tools use open, but it shipped inside separate products misusing the package. Without a shared vulnerability identifier, a security team has three unrelated changelogs to cross-reference. We worked with VulnCheck to fix that. They published CVE-2026-119025 (CVSS 4.0 7.7, High) on 2026-10-29 with all three affected ranges in one record:

Now there is one record that reaches the people running affected versions. We appreciate the speed and care VulnCheck brought to it.

What this says about MCP security

The risk: MCP is the default way coding agents, IDEs and enterprise assistants connect to tools and data, and it isn't going away. Every remote server is untrusted input with a path to the developer's machine. In the Inspector, one HTTP response during OAuth discovery was enough to run code, before a single tool was listed.

Why it happens:

• Clients trust server-chosen URLs. The server picks its own OAuth endpoints, and clients pass them to open without checking.
• The server doesn't have to start out malicious. Typosquatting, an expired domain or a domain takeover delivers the same payload.
• Fixes are slow to reach users. Over 80% of open's weekly downloads still resolve to an affected version, and a ^10.x range never resolves to 11.x.

How to fix it:

• Upgrade open and the tools that bundle it. open 11.0.0+, Inspector 2.12.0+, opencode 1.18.33+. Add an override so transitive copies of open move too.
• Validate every field the server returns. Require https (or http on loopback) and, where the spec allows, an origin that matches the configured server.
• Monitor your remote MCP servers. Track which servers your agents and IDEs connect to, and alert on domain or ownership changes.

Remote MCP servers run elsewhere, so you don't have to install and execute their code locally. That doesn't eliminate local code execution risk. The client still runs on your machine and processes the server's responses. In this case, it passed a server-chosen OAuth URL into a PowerShell command. The client needs the same scrutiny as the server.

References

• GHSA-q978-78c7-phqw (MCP Inspector)
• Inspector fix: 094847a · f7e0377
• Inspector 2.12.0
• VulnCheck CVE-2026-119025
• opencode PR #51414 · opencode
• Open and Shut (Pillar)
• open v11.0.0 fix
• GitHub dependency graph, dependent repositories and packages (checked November 5, 2026)
• npm weekly downloads, October 28 to November 3, 2026
• Official container image, cumulative downloads (checked November 5, 2026)
• AWS, Test your gateway using the MCP Inspector
• AWS Labs, AWS Knowledge MCP Server documentation
• Cloudflare, Test a Remote MCP Server
• Microsoft, azure-devops-mcp package.json (inspect script)