Five MCP attack patterns every developer should understand: tool poisoning, supply chain attacks, localhost RCE, rug pulls, and overprivileged access. Real CVEs and mitigations for each.
MCP is one of the more exciting things to happen to developer tooling in a while. And like most things that get adopted quickly, the security thinking tends to lag behind the enthusiasm.
Servers are distributed through npm and PyPI, permissions are broad by default, and the protocol doesn't enforce authentication or integrity checks out of the box. None of that is a reason to avoid MCP. It's just worth understanding before you wire it into your stack.
Here are the five attack patterns worth understanding, with real CVEs, proof-of-concept examples, and mitigations for each.
A malicious MCP server can embed hidden instructions in its tool descriptions that manipulate the LLM into doing things you never asked for. The instructions don't show up in the tool's visible behavior. They sit in the context window where the model reads them as legitimate guidance and acts accordingly.
Example: Researchers demonstrated that a malicious MCP server could silently exfiltrate a user's entire WhatsApp message history by combining a poisoned tool with a legitimate whatsapp-mcp server running in the same agent. The same technique pulled contents from private GitHub repositories via compromised personal access tokens.
How to prevent it:
MCP servers are distributed through npm, PyPI, and GitHub with no centralized vetting. Anyone can publish one. Most developers install them based on a README and a star count, which is roughly the same due diligence you'd apply to choosing a restaurant.
Example: CVE-2025-6514 (CVSS 9.6): the mcp-remote package, downloaded 437,000+ times, trusted server-provided OAuth endpoints without validation. An attacker could craft a malicious authorization URL that gets executed directly by the system's shell, achieving full remote code execution on any machine running the package.
How to prevent it:
If an MCP development tool binds to localhost without authentication, any webpage you visit can talk to it. No phishing, no downloads. Just a browser tab open while you're working.
Example: CVE-2025-49596 (CVSS 9.4): Anthropic's own MCP Inspector launched a web UI on localhost with no authentication. A malicious webpage could inject commands into the Inspector's proxy, achieving RCE on the developer's machine. At the time of disclosure, 560 exposed MCP Inspector instances were found on Shodan.
How to prevent it:
An MCP server can change its tool descriptions after you've already approved it. The initial install looks clean. The descriptions pass review. Then the server quietly updates its tool definitions to include malicious instructions, and your agent executes them with the permissions you already granted. Think of it as a bait and switch at the protocol level.
Example: This is a documented attack pattern. The official MCP specification acknowledges that servers can modify tool definitions between invocations. There is no built-in mechanism to detect or prevent this.
How to prevent it:
Most MCP servers request far more permissions than they need. A single server token might grant access to email, calendars, file storage, databases, and source code all at once. If that server gets compromised or its tool is poisoned, the attacker inherits every one of those permissions. There's also the confused deputy problem: an MCP server performs actions with its own elevated permissions rather than the user's, which can expose resources the user was never supposed to reach.
Example: An MCP server granted a personal access token with full GitHub org access. If that server's tool descriptions are poisoned (attack #1) or it receives a rug pull update (attack #4), the attacker now has read/write access to every repository in the org.
How to prevent it:
The mitigations above are per-attack-pattern. Here are the systemic practices that cover your entire MCP surface area.
Audit before you install. Read the source code. Check the tool descriptions. Look at what permissions it requests and whether those permissions match what the tool actually needs. If a server asks for write access to your filesystem and it's supposed to read calendar events, that's a problem.
Pin and hash. Lock your MCP server versions and tool definitions. If a server changes its tool descriptions between sessions, you want to know about it before your agent acts on the new instructions.
Scope credentials narrowly. One MCP server should not have a token that grants access to your entire GitHub org, your Supabase database, and your email. Separate concerns. One server, one set of minimally scoped credentials.
Monitor MCP traffic. Log what tools your agents call, what data they send, and what responses they receive. If an agent starts sending data to an unexpected endpoint, you need to know immediately.
Follow the spec. The official MCP security best practices include requiring user confirmation for sensitive operations and implementing proper consent flows. Read it. Most developers haven't.
That's a lot of surface area to cover manually, especially as the number of MCP servers in your environment grows. An all-in-one security solution like Fencer can help you cover your essentials and steer clear of common MCP risks such as tool poisoning, supply chain vulnerabilities, rug pull mutations, and issues related to overprivileged access, so you're not relying on manual audits to catch the risks that matter most.
MCP itself is a protocol specification, not a product. Like HTTP, it can be used safely or unsafely. The risks come from how MCP servers are implemented, distributed, and configured. The protocol currently lacks built-in authentication, integrity verification, and permission scoping, which means developers need to apply those controls themselves.
MCP tool poisoning is an attack where a malicious MCP server embeds hidden instructions in its tool descriptions. These instructions are invisible to the user but are read by the LLM as part of its context. The model then performs unintended actions, such as exfiltrating data or modifying files, while appearing to execute a legitimate tool call. This has been demonstrated in proof-of-concept attacks against WhatsApp and GitHub integrations.
A rug pull attack occurs when an MCP server changes its tool descriptions after a user has already approved it. The initial install looks safe, but the server later modifies its definitions to include malicious instructions. The agent executes these with the permissions already granted. Tool pinning (hashing descriptions and alerting on changes) is the primary defense.
Audit the source code of every MCP server you've installed. Check tool descriptions for hidden instructions. Verify that credentials are scoped to minimum required permissions. Ensure development tools aren't exposed on open ports. Use automated scanning tools to test your MCP configuration against known attack patterns.
