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 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 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

Source summary

Summary In affected versions, servers put no limit on how many array elements and object keys they validated in one request. One HTTP request within the default 4 MiB size limit could exhaust the server's memory, and the process aborted with JavaScript heap out of memory . No credentials are needed, unless you authenticate requests before they reach the SDK. Am I affected? Yes, if clients you do not fully trust can reach your server over HTTP. The risk is highest for McpServer tools whose input contains an array or a record. stdio-only servers are not affected. Affected versions: - @modelconte

Affected

@modelcontextprotocol/sdk >=1.3.0 <1.32.0 · @modelcontextprotocol/server >=2.0.0 <2.3.0

Fixed in

1.32.0 · 2.3.0

ID

GHSA-46jr-4wx8-v453

Source summary

Summary In affected versions, an MCP server reached over HTTP could deliver one client's responses and notifications to another client. This happened when clients shared one stateless transport, or one McpServer or Server instance. Messages were matched to a connection by JSON-RPC id alone. SDK clients number requests from 0, so ids collide in normal use. Am I affected? Yes, if more than one client can reach your HTTP endpoint and your code creates the transport or the server once at startup, instead of once per request or per session. Until this release, the README examples of @modelcontextpr

Affected

@modelcontextprotocol/server >=2.0.0 <2.3.0

Fixed in

2.3.0

ID

GHSA-jm63-cq47-j5jp

Source summary

Summary In affected versions, MCP servers reachable over HTTP put no limit on the size of a POST body or on the number of messages in a JSON-RPC batch. Large requests could exhaust the server's memory, and one long batch could block it from serving anyone else. No credentials were needed, unless your application authenticates requests before they reach the SDK. Am I affected? Yes, if clients you do not fully trust can reach your server over Streamable HTTP. A body parser such as express.json() does not protect you, because it does not limit batch length. Servers that only use stdio are not aff

Affected

@modelcontextprotocol/sdk >=1.10.0 <1.30.1 · @modelcontextprotocol/server >=2.0.0 <2.1.0 · @modelcontextprotocol/node >=2.0.0 <2.1.0 · @modelcontextprotocol/hono >=2.0.0 <2.0.1

Fixed in

1.30.1 · 2.1.0 · 2.0.1

ID

GHSA-f897-62hf-6gxq

Source summary

The plugin install flow in Claude Code and Claude Desktop checked out a marketplace's pinned commit SHA using git checkout without verifying that the resulting HEAD matched the pinned SHA. An attacker controlling a plugin's upstream repository could create a branch named identically to the pinned 40-character SHA, causing the checkout to silently resolve to the attacker's branch tip instead of the reviewed commit, resulting in attacker-controlled code being installed bypassing the pinned hash. Exploitation required a user to install a malicious plugin, pin to a safe hash, and for the plugin so

Affected

@anthropic-ai/claude-code <2.1.179

Fixed in

2.1.179

ID

GHSA-pq7j-f95f-qfcv

Source summary

Claude Code validated that a target file path resided within the project working directory at permission-check time, but re-resolved the path at write time without repeating that validation. This time-of-check to time-of-use (TOCTOU) gap allowed an attacker who could write to the workspace to atomically replace a project file with a symlink, causing Claude Code to follow the symlink and write its output to an arbitrary file outside the project sandbox. Exploitation required the ability to win a race condition against the write operation and write access to the shared workspace, enabling a lowe

Affected

@anthropic-ai/claude-code <2.1.129

Fixed in

2.1.129

ID

GHSA-5j29-h97v-84ch

Source summary

Summary In affected versions, the experimental tasks feature ( taskStore ) did not check which session created a task. Clients sharing one InMemoryTaskStore could list, read and cancel each other's tasks. Experimental tasks are deprecated. The 2026-07-28 specification replaced them with a redesigned extension. The best course of action is to stop using them. Am I affected? Only if your HTTP server passes taskStore to McpServer or Server . If grep -ri taskstore --exclude-dir=node modules . finds nothing, you are not affected. Affected versions: @modelcontextprotocol/sdk 1.24.0 through 1.31.0. T

Affected

@modelcontextprotocol/sdk >=1.24.0 <1.32.0

Fixed in

1.32.0

ID

GHSA-22jm-h49p-29qw

Source summary

Summary In affected versions, the SDK's OAuth client let the MCP server decide which authorization server received the client's OAuth credentials. Credentials were not tied to the authorization server they belong to. A malicious or compromised MCP server could name its own authorization server. With no user interaction, the client would send it: - the refresh token and client secret stored from an earlier sign-in - the client secret or signed assertion configured on a bundled provider Am I affected? Yes, if both of these hold: - your application uses the SDK's OAuth client over HTTP, through a

Affected

@modelcontextprotocol/sdk >=1.12.0 <1.31.0 · @modelcontextprotocol/client >=2.0.0 <2.2.0

Fixed in

1.31.0 · 2.2.0

ID

GHSA-6qxp-vccf-f47h

Source summary

Summary A vulnerability in AI SDK Harness credential brokering can expose host credentials to sandboxed code when an existing session is resumed with a newly introduced credential environment variable. Credential brokering normally supplies non-secret placeholders to the sandbox and substitutes real credentials outside the sandbox boundary for approved outbound requests. Affected adapters reuse the credential-placeholder map saved with the previous session without ensuring that it covers the current authentication environment. As a result, newly introduced credentials can be passed into the sa

Affected

@ai-sdk/harness-opencode <1.0.135 · @ai-sdk/harness-claude-code <1.0.137 · @ai-sdk/harness-codex <1.0.135 · @ai-sdk/harness-deepagents <1.0.133 · @ai-sdk/harness <1.0.133 · @ai-sdk/harness-acp <1.0.71

Fixed in

1.0.135 · 1.0.137 · 1.0.133 · 1.0.71

ID

GHSA-4mqq-99j3-3hmv

• 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 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

Summary In affected versions, the SDK's server-side bearer authentication had no way to check that a token was issued for your server (its audience). Where one authorization server issues tokens for several services, a valid token for another service was also accepted by your MCP server. Am I affected? Yes, if your HTTP server uses requireBearerAuth() or verifyBearerToken() , its authorization server also issues tokens for other services, and your verifyAccessToken() does not check the token's audience ( aud ) itself. Affected versions: - @modelcontextprotocol/sdk 1.6.0 through 1.31.0 - @model

Affected

@modelcontextprotocol/sdk >=1.6.0 <1.32.0 · @modelcontextprotocol/server >=2.0.0 <2.3.0 · @modelcontextprotocol/express >=2.0.0 <2.0.2 · @modelcontextprotocol/server-legacy >=2.0.0 <2.3.1

Fixed in

1.32.0 · 2.3.0 · 2.0.2 · 2.3.1

ID

GHSA-rvq5-wwqv-78pq

Source summary

Summary In affected versions, the SDK's HTTP client transports and OAuth requests followed redirects to any origin. If an MCP server or authorization server redirected a request to another origin, that origin received custom request headers (such as an X-API-Key set in requestInit.headers ) and the mcp-session-id header. On a 307 or 308 it also received the request body, including OAuth token requests with their refresh token and client secret . On current runtimes fetch already drops the Authorization header across origins. Am I affected? Yes, if your application uses StreamableHTTPClientTran

Affected

@modelcontextprotocol/sdk <1.32.0 · @modelcontextprotocol/client >=2.0.0 <2.3.0

Fixed in

1.32.0 · 2.3.0

ID

GHSA-6prh-2h8m-c8cw

Source summary

Impact The @ai-sdk/harness-acp host-tool relay did not verify that relay requests matched model-generated tool calls. Untrusted sandbox code that obtained the relay credential could invoke registered host tools during an active prompt turn. Impact depends on the tools exposed by the application. Tools requiring explicit user approval remain protected. Patches Upgrade to @ai-sdk/harness-acp 1.0.77 or later. References - https://github.com/vercel/ai/pull/21826

Affected

ai-sdk >=1.0.0

Fixed in

1.0.77

ID

GHSA-g3x3-7q3h-gmhj

• Project runs the MCP Inspector proxy (server/src/index.ts with the SSE transport branch that logs forwarded headers).
• Inspector is used to connect to an upstream MCP server over the SSE transport (not streamable-http).
• The upstream SSE MCP server requires authentication via an Authorization bearer token or custom auth headers (x-custom-auth-header(s)).
• The Inspector proxy's stdout/logs are readable by someone other than the credential holder (terminal scrollback, Docker/Kubernetes logs, CI/devcontainer logs, support bundles).

Affected

@modelcontextprotocol/inspector >=0.14.2 <=1.0.2 · @modelcontextprotocol/inspector-server >=0.14.2 <=1.0.2

Fixed in

1.0.3

ID

GHSA-8qgq-27v6-55w3

Source summary

Claude Code selected an API key stored by Claude Code, for example from an earlier /login or written directly to its configuration, ahead of the user's valid Claude Enterprise or Team sign-in when fetching the organization's server-managed settings, even though the session itself authenticated with the Enterprise or Team account. When the settings endpoint rejected that stored key, the session started without the organization's server-managed policy (such as permission deny rules, model restrictions and managed-only locks) or, if a previously cached copy existed on the machine, kept applying t

Affected

@anthropic-ai/claude-code >=2.0.68 <2.1.260

Fixed in

2.1.260

ID

GHSA-gfvf-j8jh-jxxw