What are the main MCP security vulnerabilities?

The main MCP vulnerabilities are: tool poisoning (hidden instructions in tool descriptions), rug-pull attacks (descriptions changing mid-session), credential theft through tool arguments, prompt injection in tool responses, SSRF via tool-triggered HTTP requests, session hijacking through tool inventory manipulation, and cross-server exfiltration using multiple tools in sequence.

How do MCP vulnerabilities differ from general LLM security risks?

LLM vulnerabilities like prompt injection exist in the model's input and output. MCP vulnerabilities exist in the protocol layer: tool descriptions that carry hidden instructions, tool arguments that leak secrets, tool responses that contain injection payloads, and multi-tool sequences that exfiltrate data. MCP extends the attack surface beyond the model conversation into the tool ecosystem.

Can MCP vulnerabilities be fixed by the MCP protocol itself?

Some vulnerabilities are protocol-level gaps (no built-in authentication, no response integrity). Others are architectural (tool descriptions are untrusted text that enters the agent's context window). Protocol improvements help but can't eliminate the fundamental issue: agents execute instructions from content they consume. Runtime inspection at the proxy layer catches attacks regardless of protocol version.

MCP Vulnerabilities

MCP vulnerabilities are real and growing. The Model Context Protocol gives AI agents access to external tools, and those tools introduce attack surface that didn’t exist when agents only processed text. Every MCP connection is a trust boundary, and most agents cross it without any inspection.

This page catalogs the known MCP vulnerabilities and shows what runtime defenses exist for each risk.

Vulnerability map

Vulnerability	Detection	Defense
Tool poisoning	Tool description scanning	`mcp_tool_scanning`
Rug-pull attacks	SHA-256 drift detection	`mcp_tool_scanning`
Credential theft	DLP on tool arguments	`mcp_input_scanning`
Prompt injection in responses	Response content scanning	`response_scanning`
SSRF through tools	IP/metadata/DNS checks	`internal` SSRF config
Session hijacking	Session binding	`mcp_session_binding`
Cross-server exfiltration	Chain detection	`tool_chain_detection`
Schema manipulation	Deep schema extraction	`mcp_tool_scanning`

Tool poisoning

A malicious MCP server hides instructions in its tool descriptions. When the agent calls tools/list, those instructions enter the context window. The agent follows them because it can’t distinguish documentation from commands.

The attack isn’t limited to the description field. Instructions can hide in parameter names, default values, enum options, and example values. CyberArk’s “Poison Everywhere” research demonstrated encoding exfiltration instructions in MCP tool parameter names.

Defense: Pipelock’s MCP proxy extracts text recursively from the full tool definition and scans it for injection patterns. See MCP Tool Poisoning for the full breakdown.

Rug-pull attacks

The server returns clean tool descriptions initially. After the agent starts using the tools, subsequent tools/list responses contain modified descriptions with hidden instructions. Any check that only runs at session start misses this completely.

Defense: Pipelock fingerprints every tool description with SHA-256 on first contact. Subsequent responses are compared against the baseline. Any change triggers an alert or block with a detailed diff of what changed.

Credential theft via tool arguments

An agent that has been tricked (by tool poisoning or prompt injection) passes secrets through tool arguments. The tool call looks normal, but the arguments contain API keys, SSH keys, or environment variables that the server collects.

This is the exfiltration endpoint for most MCP attacks. The poisoning gets instructions into the agent. The tool call arguments carry the stolen data out.

Defense: Pipelock scans tool call arguments for credential patterns using 48 DLP regex patterns with 6-pass normalization (NFKC Unicode, invisible character removal, leetspeak, optional whitespace, vowel folding, base64/hex decode). A secret encoded in base64 inside a tool argument still gets caught.

mcp_input_scanning:
  enabled: true
  action: block

Prompt injection in tool responses

A tool returns content that contains hidden instructions targeting the agent. The agent reads the response, processes the injected instructions, and follows them. This is indirect prompt injection delivered through the MCP channel instead of a web page.

Defense: Pipelock scans tool response content for 25 injection patterns through the same 6-pass normalization pipeline. Patterns cover jailbreak attempts, authority assertions, credential solicitation, and state manipulation in English, Chinese, Japanese, and Korean.

SSRF through tool-triggered requests

A tool tells the agent to fetch a URL. The URL resolves to a private IP (169.254.169.254 for cloud metadata, 127.0.0.1 for local services, or RFC 1918 addresses for internal networks). If the agent or proxy fetches the URL, internal services are exposed.

MCP makes SSRF worse because tool descriptions can include URLs as default values or examples. An agent following a tool’s documentation might hit an SSRF endpoint without any explicit instruction to do so.

Defense: Pipelock checks URLs after DNS resolution, not just the hostname string. This catches DNS rebinding attacks where a hostname resolves to a private IP. Cloud metadata endpoints, link-local addresses, and loopback are all blocked. DLP scanning runs before DNS resolution so secrets can’t be exfiltrated through DNS queries.

Session hijacking

A server introduces new tools mid-session that weren’t in the original tools/list response. The new tools may have poisoned descriptions, or they may shadow legitimate tools from other servers (same name, different behavior).

Defense: Session binding pins the tool inventory at session start. New tools that appear mid-session are flagged as unknown and blocked.

mcp_session_binding:
  enabled: true
  unknown_tool_action: block

Cross-server exfiltration

An agent uses Tool A from Server A to read sensitive data, then Tool B from Server B to send it somewhere. Neither call is suspicious in isolation. The exfiltration only becomes visible when you track the sequence across calls.

Defense: Tool chain detection watches for suspicious multi-tool sequences within a session. Patterns like “read file then send HTTP request” or “access credentials then call external API” trigger alerts or blocks.

tool_chain_detection:
  enabled: true
  action: block

Schema manipulation

Beyond description text, tool schemas can carry hidden payloads. Deeply nested JSON schemas with $ref pointers, recursive definitions, or extremely large enum arrays can smuggle instructions past shallow scanners. Some scanners only check the top-level description and miss instructions buried three levels deep in a parameter schema.

Defense: Pipelock’s scanner extracts text from the entire schema tree recursively, including nested properties, items, anyOf/oneOf branches, default values, and enum arrays. There’s a 10,000-tool cap per session to prevent unbounded memory from intentionally oversized schemas.

What the MCP protocol doesn’t protect against

The MCP specification defines the transport and message format. It doesn’t include:

Authentication between client and server. Any process that speaks JSON-RPC can connect.
Response integrity. No way to verify that tool output hasn’t been tampered with in transit.
Description signing. No built-in mechanism to verify that tool descriptions are authentic.
Rate limiting. Servers can return unlimited data or make unlimited calls.

These gaps exist at the protocol level. Runtime inspection at the proxy layer fills them regardless of MCP version.

MCP Vulnerabilities: Known Risks and Defenses