MCP Inspector's nine advisories: update both release lines

MCP Inspector is the Model Context Protocol project's own tool for testing MCP servers: you point it at a server, and it shows the tools, resources and prompts the server offers and lets you call them by hand. Developers building MCP servers run it on their laptops, and one advisory notes that its purpose is to be pointed at servers whose behaviour is unknown. On 21 October 2026 the project published nine security advisories for it. Two are rated critical, three high, three moderate and one low. Several let the server being inspected, or a web page, run commands on the computer running Inspector.

The fixes are in two releases, because Inspector currently has two release lines. This article sets out which one you need, what the most serious advisories describe, and how to run a tool like this more safely.

Two release lines, two fixed versions

npm lists @modelcontextprotocol/inspector with a latest tag on the 2.x line and a v1-latest tag on the older 1.x line, which an advisory describes as the security-fixes-only line. The fixed versions were published on the same day:

• 1.0.3 for the 1.x line (and the 0.x releases before it), published at 06:20 UTC on 21 October;
• 2.12.0 for the 2.x line, published at 18:35 UTC.

Which advisories apply depends on the line:

Advisory	Severity	Affected	Fixed in
GHSA-4fc4-wcmh-4g86: OAuth callback switches the transport to stdio	Critical	0.13.0 to 1.0.2	1.0.3
GHSA-6x67-4w4w-9f3w: an MCP App steals the proxy token	Critical	0.20.0 to 1.0.2	1.0.3
GHSA-wmjf-2m46-2352: no authentication when it is turned off	High	0.14.1 to 1.0.2	1.0.3
GHSA-q978-78c7-phqw: PowerShell injection on Windows and WSL	High	2.0.0 to 2.11.0	2.12.0
GHSA-vcc9-3xgm-p9v4: DNS rebinding reads tokens	High	2.0.0 to 2.11.0	2.12.0
GHSA-m5pj-3536-3xcp: no size limit on proxied responses	Moderate	0.21.2 to 1.0.2, and 2.0.0 to 2.11.0	1.0.3 and 2.12.0
GHSA-f6mc-jg3x-vq53: headers leak across redirects	Moderate	1.0.0 to 1.0.2	1.0.3
GHSA-2rq8-f55p-j2jp: session token sent to a chosen origin	Moderate	0.14.1 to 1.0.2	1.0.3
GHSA-8qgq-27v6-55w3: SSE headers written to the log	Low	0.14.2 to 1.0.2	1.0.3

One disagreement between sources is worth knowing about. The advisory on missing authentication (GHSA-wmjf-2m46-2352) lists only 1.x versions as affected, but its own text says it was confirmed on 2.5.0 as well. If you run 2.x, upgrade to 2.12.0 anyway, and don't rely on the affected range to rule that issue out.

The two critical advisories

Both critical advisories end the same way: Inspector's local proxy starts a command of the attacker's choosing. That proxy exists so that Inspector can launch local MCP servers over stdio, which means starting a process is its job. The bugs are about who gets to ask it.

An OAuth callback that changes the connection (GHSA-4fc4-wcmh-4g86). You connect Inspector to a remote server, the server asks you to sign in, and it chooses the authorisation server. After sign-in, the browser is sent back to Inspector's callback page with extra query parameters appended: a stdio transport, a command and its arguments. Inspector read its connection settings from the page address and reconnected after the token exchange, so it started that command.

A token taken by an MCP App (GHSA-6x67-4w4w-9f3w). MCP Apps let a server send interactive content that the client renders. Inspector rendered it in a sandbox served from the proxy's own address, so the proxy's origin check passed. Through a link-opening message and a crafted configuration parameter, the content could make Inspector send its proxy token to another address, and with the token it could ask the proxy to start a command.

Older defences that did not hold

Two of the high advisories revisit CVE-2025-49596, the 2025 vulnerability that led Inspector to add a session token and an origin check to its proxy.

• When authentication is turned off (GHSA-wmjf-2m46-2352). Inspector has a setting, DANGEROUSLY_OMIT_AUTH, that removes the token check. The origin check that remained allowed requests with no Origin header, which is what a non-browser client sends, so anything that could reach the port could start a process.
• DNS rebinding (GHSA-vcc9-3xgm-p9v4). On the 2.x line, the page that serves Inspector's interface included the API token and sat outside the protected routes, and the server did not check the Host header. After a DNS rebinding attack, a web page could read the token and then the stored OAuth tokens. The advisory notes that starting a process stayed blocked in this case.

A familiar Windows bug

The third high advisory (GHSA-q978-78c7-phqw) affects the 2.x line on Windows and in WSL. A remote server answers with a sign-in challenge and names an authorisation address of its choosing. Inspector opens it with the open package, version 10, which places the address inside a PowerShell double-quoted string without escaping it, so a $(...) expression in the URL runs. This is the same class of flaw that we covered in opencode's MCP OAuth fix. The advisory notes that open 11 escapes the target, and that a caret range on 10.x never reaches 11, so routine updates do not pick it up.

What to do

1. Upgrade. On the 2.x line, run 2.12.0 or later; on the 1.x line, 1.0.3 or later. If Inspector is run with npx and a pinned version, change the pin.
2. Never turn authentication off on a machine where anything else can reach Inspector's ports, and keep it bound to the local machine.
3. Inspect untrusted servers somewhere disposable. Inspector's purpose is to connect to servers whose behaviour you don't know yet, and several of these advisories need nothing more than that connection. A virtual machine or container with no credentials, no access to your code and no saved sign-ins limits what a malicious server can reach.
4. Close Inspector when you are done rather than leaving it running in the background while you browse.
5. Rotate tokens stored in Inspector, such as OAuth tokens for remote servers, if you ran an affected version against servers you don't control.

None of the advisories has a CVE number at the time of writing, so scanners that key on CVEs may not report them. Check the version directly.