Claude MCP Server Security: A Practical Hardening Guide

What an MCP server actually exposes

An MCP server is a JSON-RPC endpoint that publishes a catalogue of tools, resources, and prompts. When connected to Claude Desktop, Claude Code, or any MCP-compatible client, every tool description and resource snippet enters the model's context window. That means the server is not just an API surface — it is an instruction surface.

• Tools: function-like primitives the model can invoke (write_file, run_sql, send_email).
• Resources: arbitrary text/binary blobs streamed into context (logs, files, query results).
• Prompts: server-provided prompt templates the user or model may inject into the conversation.
• Transports: stdio (local subprocess), SSE, or streamable HTTP — each with different auth and origin guarantees.

Five exploit classes that already exist in the wild

1. Tool poisoning / rug-pull descriptions

A tool registered as get_weather can be re-registered after install with a description containing override instructions. Clients that cache the original schema but execute the new one are vulnerable.

2. Indirect prompt injection through resources

MCP filesystem and web-fetch servers stream third-party content directly into context. An attacker who controls a fetched page controls the model's instructions for the rest of the session.

3. Confused-deputy in cross-server flows

When two MCP servers are loaded simultaneously, server A can describe a tool that nudges the model to call server B with attacker-controlled arguments — extracting secrets server A could never read directly.

4. Path traversal and arbitrary write

Many community servers accept untrusted file paths and resolve them with naive path.join. CVE-2025-54794 (the Claude Desktop MCP RCE) is exactly this pattern.

5. Transport-level abuse

SSE servers bound to 0.0.0.0 with no origin check expose every connected tool to every browser tab on the user's machine. DNS-rebinding upgrades this to remote.

A 14-point hardening checklist

1. Pin tool schemas at install time; refuse silent re-registration.
2. Sandbox the server process (seccomp, AppArmor, or a container).
3. Drop network egress unless the server's job requires it.
4. Enforce an allowlist of filesystem roots — reject symlinks across roots.
5. Validate every path with realpath and reject ../ even after normalisation.
6. Bind SSE/HTTP transports to 127.0.0.1 only; verify Origin headers.
7. Require a per-session bearer token for HTTP transports.
8. Log every tool invocation with arguments and caller identity.
9. Mark resources from untrusted origins with a visible <untrusted> tag.
10. Strip or escape HTML, scripts, and ANSI escapes from streamed resources.
11. Cap resource size; truncate before they dominate context.
12. Never embed secrets in tool descriptions — the model will quote them back.
13. Pin server version in mcp.json; review changelogs before bumping.
14. Run a red-team prompt suite (see /prompts) against your server on each release.

How to triage a public MCP server in 10 minutes

# 1. Look at every tool description as if it were a prompt
rg -n "description" path/to/server | less

# 2. Audit every filesystem and shell sink
rg -nE "(spawn|exec|shell|writeFile|unlink|rmSync|child_process)" .

# 3. Audit network egress
rg -nE "(fetch|axios|got|http\.request)" .

# 4. Check transport binding
rg -nE "(0\.0\.0\.0|listen\(|host:)" .

If any of those return shell-sink calls fed by tool arguments, treat the server as untrusted and run it inside a container with no host mounts.

FAQ