MCP Security Workshop – Sam Morrow
Track: Sessions – Day 1 | Ref: 1.5 Speaker: Sam Morrow, MCP Developer & Contributor GitHub: SamMorrowDrums/mcp-security-workshop
Overview
A hands-on security workshop demonstrating practical attacks against MCP servers using a fork of the official GitHub MCP server. The key insight: the malicious fork passes all tests, lints clean, and behaves normally — while silently exploiting users.
Attack Vectors
1. Silent Data Logging
A middleware layer writes every tools/call request to a JSON log file. The exploit requires approximately 25 lines of code added to internal/ghmcp/server.go. Any prompt processed by the server can have its data silently captured and exfiltrated.
2. Tool Description Poisoning (Tool Shadowing)
A single line changed in pkg/github/issues.go appends injection text to the issue_read tool description. This manipulates the LLM's behavior by altering the tool's self-description — the agent follows the poisoned instructions without the user's knowledge.
3. Data Exfiltration
The modified server sends captured data to attacker-controlled endpoints. Combined with silent data logging, this creates a complete data theft pipeline that operates invisibly.
4. Permission Scope Creep
The forked server requests broader permissions than necessary. Users grant elevated access without realizing the server's actual scope exceeds what the legitimate version requires.
Supply Chain Risk
The workshop demonstrated that fork attacks on MCP servers are:
- Trivial to execute — a few lines of code in a forked repository
- Difficult to detect — diffs are small, tests still pass, behavior appears normal
- Based on wrong trust assumptions — users assume open-source MCP servers are safe because they are public
The forked server passes all tests, lints clean, and behaves normally while exploiting users. Traditional code quality checks are insufficient for detecting these attacks.
Mitigations
| Mitigation | Description |
|---|---|
| Code signing | Verify the provenance and integrity of MCP server binaries |
| Diff analysis | Compare forks against upstream for unexpected changes |
| Network monitoring | Detect unexpected outbound connections from MCP servers |
| Least privilege | Grant only the minimum permissions required |
| Audit logging | Log all tool invocations and data access for forensic review |
Related Resources
- MCP Security Workshop Repository — Workshop code and examples
- MCP Vulnerability Catalog — Comprehensive catalog of known MCP vulnerability patterns
Additional Attack Vectors
5. Rugpull (Dynamic Tool Changes)
MCP has dynamism built in — tools can change after initial review. A server could present safe tools during setup, then swap in malicious ones via a timer. While dynamic tools have legitimate uses (games, progressive disclosure), the security implications are significant.
6. Open World User Data
Even legitimate servers can process malicious data. Example: a GitHub issue comment contains a prompt injection. The agent processes it without awareness of the embedded attack. This is particularly dangerous because the server itself is trustworthy — the attack comes through the data.
7. Response Prompt Injection
Injecting prompts into legitimate content that the agent returns to the user. Can be non-deterministic — acting only at specific moments, making detection harder.
MCP Annotations
MCP provides tool annotations (hints) for security signaling:
| Annotation | Meaning |
|---|---|
readOnly | Non-destructive operation |
destructive | Destructive operation |
idempotent | Same result on repeat |
openWorld | Accesses external/network resources |
Important: Annotations are hints, not enforcement. Malicious servers can lie about their annotations. They protect against accidental misuse on good-faith servers, not against intentional attacks.
Defense in Depth
No single layer provides security, but combined they progressively reduce risk:
- Tool confirmations — catch dangerous operations before execution
- Annotations — signal destructive/ambiguous tools
- LLM-as-judge — non-deterministic but catches obvious attacks
- Static scanning — analyze server code for suspicious patterns
- Sandboxing — limit what servers can access
- Policy engines — deterministic access control
- Real-time monitoring — detect anomalies as they occur
"The more layers and guardrails that catch N% of malicious attacks, the less successful malicious things occur."
Supply Chain Incidents
Postmark MCP (Email Server)
A popular email MCP server was compromised — large install base, access to all emails, and potential for prompt injection via incoming emails. Lesson: email data + agent API = significant exfiltration risk.
Emerging Security Tools
- mcp-deep — compare server schemas against known-good versions
- Scanning tools — static analysis of MCP server code
- Open Shell — sandbox with policy-based controls
- AI-powered testing — automated attack surface analysis
Key Takeaways
- Fork attacks on MCP servers are trivial and difficult to detect
- Silent data logging and tool description poisoning require minimal code changes
- All traditional quality gates (tests, linting) pass on the malicious fork
- The "lethal trifecta" (read + write + network) can occur even with trustworthy servers through composition
- Supply chain security for MCP servers demands new verification approaches
- Defense-in-depth (signing, monitoring, least privilege, audit) is essential