SSE auth/custom headers are logged verbatim by the Inspector proxy.
Does it affect you?
Timeline
21 Oct- Published by GitHub advisory21 Oct
- Seen by Patchwire23 Oct
- Fix released21 Oct
Versions of @modelcontextprotocol/inspector
Versions of @modelcontextprotocol/inspector-server
Related alerts(8)
Same packages- Project uses MCP Inspector v2 (@modelcontextprotocol/inspector) at version 2.7.0 or earlier.
- The Inspector Node backend's POST /api/fetch proxy route is in use for MCP traffic or OAuth work.
- Inspector connects to (or is redirected during OAuth/CIMD to) an untrusted or misbehaving server that can return a very large or unbounded response body.
- Affected
- @modelcontextprotocol/inspector >=2.0.0 <=2.11.0 · @modelcontextprotocol/inspector >=0.21.2 <=1.0.2 · @modelcontextprotocol/inspector-server >=0.21.2 <=1.0.2
- Fixed in
- 2.12.0 · 1.0.3
- ID
- GHSA-m5pj-3536-3xcp
- Project runs the MCP Inspector (@modelcontextprotocol/inspector) proxy/web app, e.g. version 2.2.0, with the CVE-2025-49596 fix (auth token + Origin check).
- Inspector is served on loopback (default port 6274) with default config.
- Inspector does not validate the Host header on its routes.
- GET / or the SPA fallback route serves HTML with the injected API token without authentication.
- The developer visits an attacker-controlled web page while the Inspector is running.
- The developer's browser lacks DNS-rebinding / Private Network Access mitigations.
- Affected
- @modelcontextprotocol/inspector >=2.0.0 <=2.11.0
- Fixed in
- 2.12.0
- ID
- GHSA-vcc9-3xgm-p9v4
- Project uses MCP Inspector (CLI, TUI, or web server client) with the npm "open" dependency at v10.x (pinned "^10.2.0"), not v11.
- Inspector runs on Windows, or on WSL outside a container.
- User connects Inspector to a remote MCP server that answers 401 and serves OAuth discovery documents with an attacker-chosen authorization endpoint.
- OAuth auto-open is enabled (MCP_AUTO_OPEN_ENABLED is not "false" and Vitest is not running).
- stderr is a TTY (Inspector run interactively).
- Affected
- @modelcontextprotocol/inspector >=2.0.0 <=2.11.0
- Fixed in
- 2.12.0
- ID
- GHSA-q978-78c7-phqw
- Project uses @modelcontextprotocol/inspector (tested version 0.21.2).
- The MCP Inspector client has a proxy session token (MCP_PROXY_AUTH_TOKEN) configured, e.g. prefilled by default at startup.
- The user opens a crafted Inspector URL whose MCP_PROXY_FULL_ADDRESS query parameter points to an attacker-controlled HTTP endpoint.
- Affected
- @modelcontextprotocol/inspector >=0.14.1 <=1.0.2 · @modelcontextprotocol/inspector-client >=0.14.1 <=1.0.2
- Fixed in
- 1.0.3
- ID
- GHSA-2rq8-f55p-j2jp
- Project runs MCP Inspector v1.0.0 or later, which includes the hand-rolled /fetch proxy redirect loop from commit d40c1c94.
- The Inspector proxy's /fetch endpoint is used to reach remote resources such as OAuth discovery/token endpoints.
- Proxied requests carry Authorization headers or Cookie headers.
- The user connects the Inspector to a malicious or compromised remote MCP server that can return a 3xx redirect to a different origin.
- Affected
- @modelcontextprotocol/inspector >=1.0.0 <=1.0.2 · @modelcontextprotocol/inspector-server >=1.0.0 <=1.0.2
- Fixed in
- 1.0.3
- ID
- GHSA-f6mc-jg3x-vq53
Source summary
Details The tool injects the MCP App contents into a "sandbox". This sandbox can exec JS. And this sandbox's location is http://127.0.0.1: /sandbox . Proxy Server Protections Proxy has 2 layers of defence - 1. Origin check to block DNS Rebinding. It only adds client UI port in allowed origins. 2. Auth token validation with x-mcp-proxy-auth header. The origin check is a non blocker - since the malicious MCP app is running on proxy port, its "same origin" as proxy server. Browser's don't send origin header in same origin requests. js if (origin && !allowedOrigins.includes(origin)) { console.erro
- Affected
- @modelcontextprotocol/inspector >=0.20.0 <=1.0.2 · @modelcontextprotocol/inspector-client >=0.20.0 <=1.0.2 · @modelcontextprotocol/inspector-server >=0.20.0 <=1.0.2
- Fixed in
- 1.0.3
- ID
- GHSA-6x67-4w4w-9f3w
Source summary
Summary A malicious remote MCP server can abuse the OAuth callback to switch MCP Inspector from the original remote HTTP transport to stdio and execute an arbitrary local command. Details 1. The user connects to an attacker-controlled remote MCP server. 2. The server returns an OAuth challenge and points Inspector to an attacker-controlled authorization server. 3. After authorization, the attacker redirects the browser to Inspector’s callback URL and appends Inspector configuration parameters: text /oauth/callback ?code=valid-code &state=valid-state &transport=stdio &serverCommand= &serverArgs
- Affected
- @modelcontextprotocol/inspector >=0.13.0 <=1.0.2 · @modelcontextprotocol/inspector-client >=0.13.0 <=1.0.2
- Fixed in
- 1.0.3
- ID
- GHSA-4fc4-wcmh-4g86
- Project runs @modelcontextprotocol/inspector (confirmed vulnerable: 0.14.3, 1.0.2, or 2.5.0).
- Inspector is started with authentication disabled via DANGEROUSLY_OMIT_AUTH=true.
- Attacker can send direct non-browser HTTP requests without an Origin header to the Inspector server (port 6277 /stdio in v1, port 6274 /api/mcp/connect in v2).
- Affected
- @modelcontextprotocol/inspector >=0.14.1 <=1.0.2 · @modelcontextprotocol/inspector-server >=0.14.1 <=1.0.2
- Fixed in
- 1.0.3
- ID
- GHSA-wmjf-2m46-2352