MCP Server Security Checklist (2026)

Dump tools/list from each server and read the raw JSON, not the client's rendered view. Look in descriptions, parameter descriptions, enum values, examples and annotations for imperative text addressed to the model: "before using this tool", "do not mention", references to other tools, or to files such as ~/.ssh.

Strip or flag tag-block (U+E0000 to U+E007F), variation-selector (U+FE00 to U+FE0F) and zero-width (U+200B, U+200C, U+200D, U+2060) characters. OWASP LLM01:2026 lists them as invisible carriers of instructions.

The known example: in April 2025 Invariant Labs published a researcher demonstration on Cursor in which a tool claiming to add two numbers hid instructions to read the MCP config file and the user's SSH key and pass them in a tool parameter; the agent complied.

Find every place the client reads annotations (for example to auto-approve "read-only" tools). For servers you do not control, that path must behave as if the annotation were absent. The schema note says every ToolAnnotations property is only a hint that may not describe the tool's behaviour faithfully, and that clients should never make tool use decisions based on annotations from untrusted servers. Test: serve a tool marked readOnlyHint: true that writes data, and confirm the client still asks.

Snapshot tools/list at approval time and store a hash per tool. On every connection, and on each notifications/tools/list_changed, diff against the snapshot. Compare per credential: the spec allows the tool set to change over time and to vary by the authorization presented on the request.

Pinning a package version does not cover a remote server. OWASP LLM01:2026 also notes that pinning does not stop a payload shipped in the pinned version, or description poisoning that leaves the version unchanged, so the content hash matters more than the version string.

List the tools the model actually sees across all connected servers. Two search or send_email tools from different servers is a collision. The spec says aggregating clients SHOULD implement a disambiguation strategy such as prefixing tool names with a server identifier, and SHOULD NOT rely on the server name from serverInfo. Then search each description for the names of tools that belong to other servers: Invariant Labs showed a description that modified the agent's behaviour toward a trusted server's tool.

Grep tool definitions for keys, tokens, connection strings, internal URLs and phrases such as "only admins may". Any rule written in a description must also be enforced in the tool handler (see AU-5).

Get a valid token from the same authorization server for a different resource and call a tool with it. The server must answer 401; the spec says invalid or expired tokens MUST receive HTTP 401.

Read the code path: the audience (aud) check must run in your token verifier, not only at a gateway. GHSA-rvq5-wwqv-78pq (October 2026): server bearer authentication in the MCP TypeScript SDK accepted tokens issued for a different service. Affected: @modelcontextprotocol/sdk 1.6.0 through 1.31.0 (fixed in 1.32.0) and the 2.x server packages listed in the advisory. Upgrading alone changes nothing: set expectedResource and return the token's audience as AuthInfo.resource, or reject any token whose aud does not include your server inside verifyAccessToken().

Trace each upstream call. The Authorization header sent upstream must carry a token the upstream authorization server issued to your server, never the inbound bearer token. Grep for code that copies the incoming Authorization header into outbound requests.

Check the protections the spec lists as MUST for proxy servers:

• -A per-user registry of approved client_id values, checked before the third-party flow starts
• -A consent page that names the client, shows the third-party scopes and the registered redirect_uri, has CSRF protection and blocks framing (frame-ancestors or X-Frame-Options: DENY)
• -If consent is tracked in cookies: the __Host- prefix, Secure, HttpOnly, SameSite=Lax, cryptographically signed (or server-side sessions instead), and bound to the client_id
• -Exact string matching on redirect_uri
• -A random, single-use state with a short expiry, set only after consent

Test: sign in once through the legitimate client, register a second client with a redirect URI you control, then open a crafted authorization link for it. The proxy must show its own consent screen.

Review scopes_supported and the WWW-Authenticate challenges your server sends. The spec lists these as common mistakes: publishing all possible scopes in scopes_supported; wildcard or omnibus scopes (*, all, full-access); returning the entire scope catalog in every challenge; treating claimed scopes in a token as sufficient without server-side authorization logic. Call a privileged tool with a basic token and confirm you get a scope challenge, not the action.

With two test users, call each tool with the other user's object IDs (records, file paths, handles) and expect a denial. The spec lets a server return only the tools a caller's scopes permit, but the call itself must still be checked: a hidden tool is not a protected tool.

Capture the authorization and token requests. resource must appear in both and equal the server's canonical URI. code_challenge_method must be S256. The client must refuse to proceed when the authorization server's metadata has no code_challenge_methods_supported.

Connect a client that already holds credentials for a legitimate authorization server to a test MCP server whose metadata names a different authorization server. No stored refresh_token or client_secret may be sent to it.

GHSA-6qxp-vccf-f47h (October 2026): in the official MCP TypeScript SDK, a malicious or compromised MCP server could make the client send stored OAuth credentials to an authorization server of its choosing. Affected: @modelcontextprotocol/sdk from 1.12.0 to before 1.31.0, and @modelcontextprotocol/client from 2.0.0 to before 2.2.0 (for 2.x only in the cases the advisory lists). Upgrading is not enough on its own: credentials saved before the upgrade need an issuer or must be cleared, and bundled providers need expectedIssuer.

Serve test metadata with javascript:, data:, file: and vbscript: authorization URLs, and with URLs containing shell metacharacters; the client must reject all of them. The spec says clients MUST NOT use shell commands such as cmd.exe, sh or PowerShell to open URLs, MUST sanitize and validate all URLs received from servers, and lists logging suspicious authorization URLs among the input-sanitization steps. CVE-2025-6514 affected mcp-remote from 0.0.5 and was fixed in 0.1.16.

Point the client at a test server whose resource_metadata, authorization_servers or token_endpoint values name http://169.254.169.254/, http://localhost:6379/ or a 10.x address, and at a public URL that redirects to one. The spec says clients deployed to a server MUST consider SSRF, and SHOULD require HTTPS, block private and reserved ranges, apply the same checks to redirect targets, and consider an egress proxy. It also warns not to write IP validation by hand, and to watch for DNS rebinding between check and use.

Send requests with a foreign Origin (for example https://attacker.example) and confirm HTTP 403. The response body MAY carry a JSON-RPC error with no id.

Run lsof -i or netstat while the server is up: a listener on 0.0.0.0 is a finding. Call the HTTP endpoint without credentials and expect a rejection. CVE-2025-49596 affected MCP Inspector below 0.14.1: missing authentication between the Inspector client and proxy allowed unauthenticated requests to launch MCP commands over stdio.

Create a handle as user A, then call the tool with it as user B: expect a denial. Check that handles come from a secure random generator (not sequential IDs), expire, and that stored state is keyed as <user_id>:<handle> with the user ID taken from the verified token, not from the request. For servers with no authentication, the handle is a bearer token: check its entropy (for example a UUIDv4) and its lifetime.

Open a session with token A, then send a request with the same session ID and token B, or no token. The server must reject it.

GHSA-jpw9-pfvf-9f58 (CVE-2026-52869, published 16 July 2026): the MCP Python SDK mcp up to 1.27.1 routed SSE and stateful Streamable HTTP requests to a session by session ID alone, so anyone who learned or guessed a session ID could send messages on it. Fixed in 1.27.2.

List every input property with an x-mcp-header annotation and confirm none is sensitive. Send a request whose Mcp-Param-* header disagrees with the value in the body: the server must reject it with 400 and JSON-RPC error -32020 (HeaderMismatch).

Use additionalProperties: false, enums, formats and length limits in inputSchema (for a tool with no parameters the spec recommends { "type": "object", "additionalProperties": false }). Fuzz each tool with shell metacharacters, ../ path traversal, SQL fragments and oversized values. Pass arguments to processes as argument arrays and to databases as parameterised queries. Do not fetch network $ref URIs while validating: the spec says implementations MUST NOT automatically dereference them.

For each tool that returns text someone else wrote (tickets, issues, emails, pages, documents), plant an instruction in that text and check what reaches the client. Labelling third-party text as data reduces injection success in non-adaptive tests only, so it complements, not replaces, the approval and permission items in the AI Agent Security Checklist.

In May 2025 Invariant Labs showed a malicious public GitHub issue steering an agent to copy private-repository data into a public pull request, and noted it "is not a flaw in the GitHub MCP server code itself".

Check where results are passed to the model. Results that fail the declared outputSchema should be rejected, not forwarded. Feed a result containing an instruction to call another tool and confirm the client either strips it or the following call needs approval.

Drive one tool in a tight loop from a test client and confirm throttling. Check the client aborts a tool call that never returns.

Search the server for elicitation requests whose fields ask for passwords, API keys, access tokens or payment details: each is a MUST NOT violation. For URL-mode requests, check the URL carries no user data and does not itself grant access.

Add a server through your client's one-click flow with a long command that hides && curl ... after the visible part. The dialog must show the full command, mark it as code execution, and let the user cancel. The spec's own example of a malicious startup command chains npx with curl -X POST -d @~/.ssh/id_rsa.

From inside the server process, try to read ~/.ssh, the browser profile and other servers' configs, and to open an outbound connection. Each should fail unless explicitly granted. If a local proxy spawns stdio servers, the spec adds: sandbox the spawned processes, restrict their file access, log all stdio usage and require extra authorization for dangerous commands.

Collect the MCP client configuration files from developer machines and agent deployments, list remote server URLs seen in egress logs, and compare both against the approved list.

Check lockfiles exist and are enforced in CI. Subscribe to the GitHub advisory database for the packages you depend on. Fixed versions for the advisories cited in this checklist: mcp-remote 0.1.16 (CVE-2025-6514), MCP Inspector 0.14.1 (CVE-2025-49596), MCP Python SDK 1.27.2 (GHSA-jpw9-pfvf-9f58), MCP TypeScript SDK 1.31.0 or @modelcontextprotocol/client 2.2.0 (GHSA-6qxp-vccf-f47h), plus expectedIssuer on bundled providers and issuer added to (or clearing of) credentials saved before the upgrade; and 1.32.0, or @modelcontextprotocol/server 2.3.0 (with @modelcontextprotocol/express 2.0.2 if used), with expectedResource set and the token audience returned as AuthInfo.resource (GHSA-rvq5-wwqv-78pq).

For each third-party server, write down the data classes it can see through tool arguments and context, and disable unused tools in the client configuration. Check whether context from one task or user can reach a server meant for another.

Run one tool call end to end and find its record on both client and server. Confirm the agent and its tools have no write or delete access to the audit store.

Grep a day of logs and traces for bearer tokens, refresh_token, API key prefixes and email addresses. Check who can read the logs; the spec says implementations should control log access, and that clients and servers must store tokens securely.

Trigger each event in a test environment and confirm a log line with a correlation ID. The spec's scope guidance says to log elevation events (scope requested, granted subset) with correlation IDs, and its URL validation section lists logging suspicious authorization URLs.