Analysis
MCP Security - OWASP Cheat Sheet Series
Publication date not yet evaluated · Added · 6 reports owasp.org
Page published · Page updated
Coverage timeline
Why it matters
MCP tool descriptions are prose injected straight into an LLM's context, so a poisoned or hijacked server becomes a context-window write primitive that scanning alone cannot reliably clear — defenders need version pinning and runtime monitoring to catch emergent toxic flows.
A practical guide to Model Context Protocol (MCP) security frames MCP servers as untrusted input whose tool descriptions are injected directly into an agent's context window, and catalogs four documented attack classes: tool poisoning, tool shadowing, rug pulls, and toxic flows. The write-up explains the limits of textual scanning and cites real-world cases, including the malicious postmark-mcp npm package (v1.0.16, Sept 2025) that BCC'd emails to an attacker and the Shai-Hulud 2.0 worm that targeted packages named mcp-server.
Summary
This is a defensive guidance article on Model Context Protocol (MCP) security. Its core thesis is that MCP servers must be treated as untrusted input because tool names, descriptions, and JSON schemas are injected directly into an agent's context window, where prose descriptions function as instructions to the model.[0]
The guide catalogs four documented MCP attack classes — tool poisoning, tool shadowing, rug pulls, and toxic flows — and explains the limits of static scanning: pattern-based scanners catch known shapes but over-flag ordinary imperative instructions and miss obfuscated, indirected, or emergent (multi-call) abuse. Accordingly a clean scan should be treated as one input, not as clearance.[0]
The article grounds its guidance in two real supply-chain incidents: the postmark-mcp npm package (v1.0.16, September 17, 2025), described as the first documented malicious MCP server in the wild, and the Shai-Hulud 2.0 npm worm (November 2025) that specifically targeted packages named mcp-server. It frames MCP servers as npm dependencies with a context-window write primitive and offers a practical checklist for defenders.[0]
A large-scale academic study of MCP servers independently corroborates the ecosystem risk, evaluating 1,899 open-source servers and finding eight distinct vulnerabilities, 7.2% with general vulnerabilities, and 5.5% exhibiting MCP-specific tool poisoning, while advocating for MCP-specific vulnerability detection and stronger governance.[35]
How it works
MCP hands tool names, descriptions, and JSON schemas to the model as context. Because a description is prose and prose reads as instructions, a malicious server can embed directives such as reading a user's .env file and exfiltrating its contents via a tool parameter — while most clients render only the tool name in their UI, hiding the payload from the operator. This is tool poisoning.[0]
Tool shadowing / cross-origin escalation exploits a trust-boundary mismatch: trust is enforced per-server, but the context window is shared across all connected servers. A malicious server can define a tool that shadows a trusted one, or add instructions that change how the agent uses a different server's tools.[0]
Rug pulls exploit the fact that approval happens once while tool definitions are fetched every session; a server reviewed as benign can return different, malicious tool descriptions later. Toxic flows chain individually benign calls (e.g., read a file, then post to a webhook) into a harmful sequence that textual scanning cannot detect because the harm is emergent rather than textual.[0]
Independent empirical analysis of MCP servers confirms that most identified vulnerabilities are MCP-specific rather than traditional: of eight distinct vulnerability types found across 1,899 servers, only three overlap with traditional software vulnerabilities, underscoring the need for MCP-specific detection techniques.[35]
Affected versions and patch status
| Product | Affected | Patch status |
|---|---|---|
| postmark-mcp (lookalike npm package) | v1.0.16, published September 17, 2025; 1,643 total downloads | Identified as malicious; reported as first documented malicious MCP server in the wild[0] |
Indicators of Compromise
| Type | Indicator | Context |
|---|---|---|
| domain | giftshop.club | Attacker-controlled address that received BCC-redirected email from the malicious postmark-mcp v1.0.16 package, estimated at 3,000-15,000 emails per day.[0] |
| other | npm package postmark-mcp v1.0.16 | Lookalike npm package whose v1.0.16 silently added a hidden BCC recipient to outbound mail; described as the first documented malicious MCP server in the wild.[0] |
Key takeaways
- Treat MCP servers as untrusted input: their tool descriptions are injected into the model's context, so prose descriptions can act as hidden instructions that operators never see.[0]
- Static scanning is a pre-flight input, not a guarantee — it over-flags legitimate imperative instructions and misses obfuscation, URL indirection, novel phrasing, and emergent toxic flows, so a clean report is never clearance.[0]
- The MCP attack surface is also an npm supply-chain surface: real incidents (postmark-mcp, Shai-Hulud 2.0) show small install bases and name-targeted worms can inflict real harm, so version pinning, package provenance checks, and runtime monitoring are all required.[0]
- Empirical measurement supports MCP-specific defenses: across 1,899 servers, 5.5% exhibited MCP-specific tool poisoning and most identified vulnerabilities did not overlap with traditional software flaws, reinforcing the case for MCP-specific detection and governance.[35]
Defensive actions
- Pin every MCP server version and re-scan after any version bump.: Unpinned servers silently re-approve new tool definitions every session, enabling rug pulls where a previously-reviewed server mutates its tools; pinning plus re-scanning is the specific countermeasure.[0]
- Scan MCP configs before first run and manually read tool descriptions for any server touching credentials, mail, or source control.: Scanning catches known-shape payloads (tool poisoning, some rug pulls) but over-flags and under-catches, so human review of high-sensitivity servers is needed and a clean scan is not clearance.[0]
- Prefer fewer connected servers.: Because the context window is shared while trust is per-server, every additional connected server widens the tool-shadowing and cross-origin escalation surface.[0]
- Add runtime monitoring of MCP tool calls alongside shell and file events.: Toxic flows are emergent across benign calls and only appear at runtime, so static pre-flight scanning cannot detect them.[0]
- Vet the package and its provenance, not just the protocol.: postmark-mcp was fundamentally an npm supply-chain attack that happened to speak MCP, and worms like Shai-Hulud 2.0 target packages by name (e.g., mcp-server).[0]
Changelog
- Incorporated a large-scale empirical study of 1,899 open-source MCP servers that quantifies ecosystem risk (eight distinct vulnerability types, 7.2% general vulnerabilities, 5.5% MCP-specific tool poisoning), independently corroborating the guidance article's claims.[35]