Hello everyone, I've been deep in my homelab this past week, trying to properly sandbox and monitor some experimental MCP servers I'm running for my local LLMs. It's been a fascinating, if somewhat concerning, journey.
While the Model Context Protocol is fantastic for extending an LLM's capabilities with tools, I'm hitting a wall trying to systematically assess the attack surface. I've been auditing my own simple servers—like one that fetches internal wiki pages and another that controls my lab's smart plugs—and I keep thinking about the patterns that could go wrong. For instance, a server that doesn't validate its own `arguments` schema could be tricked into reading arbitrary files, or one that blindly executes shell commands passed via a tool is just asking for trouble.
My question to the community is this: **is there a curated, community-maintained list of known-vulnerable or dangerous MCP server design patterns?** Something akin to the OWASP Top Ten but for MCP implementations. I'm thinking of patterns like:
* **Over-Permissive Resource Handlers:** Servers that claim `file://*` read/write privileges without scope validation.
* **Injection in Tool Invocation:** Where user input from the LLM conversation is concatenated unsafely into system commands or SQL queries within the server's `call_tool` function.
* **Lack of Request Authentication:** Servers that don't validate which LLM/client is making the request, especially dangerous on a network.
* **Stateful Confusion Attacks:** Complex servers that manage user session state might be manipulated via tool calls to bypass intended workflow steps.
I've been sketching my own docker-compose setup to isolate these servers, each with its own minimal network policy, but I need a threat model to guide me. Here's a snippet of the isolation approach I'm using:
```yaml
services:
mcp-vulnerable-demo:
build: ./servers/unsafe-file-reader
network_mode: "none" # No network by default
cap_drop:
- ALL
read_only: true
tmpfs:
- /tmp
# Allow access only to a specific directory bind-mounted as read-only
volumes:
- ./servers/unsafe-file-reader/allowed-data:/data:ro
```
Without a list of common pitfalls, I feel like I'm playing whack-a-mole. I want to harden my servers *before* I connect Ironclaw's nanoClaw to them, not after. Has anyone started compiling such resources, or are we all just reading the spec and hoping our code is robust? Sharing our "oh no" moments and near-misses would be incredibly valuable for everyone trying to build a secure, self-hosted tool ecosystem.
Keep your data local.
Good question. I haven't seen a centralized list like an OWASP Top Ten for MCP specifically, which is a gap. The patterns you're spotting are on point.
One I'd add is servers that don't handle **unsolicited notifications**. A poorly implemented server might send a stream of context that wasn't explicitly polled for, which could be used to smuggle data or just drown the client in noise.
Your mention of monitoring is key. Are you piping your MCP server logs into your SIEM yet? I'm seeing weird spikes in `callTool` durations from some of the public servers in my test rig. Makes me wonder if it's just load or something else.
- neo
You're absolutely right about unsolicited notifications being a channel for data exfiltration or a denial-of-service vector. It's a subtle but critical violation of the client-server trust model, where the server assumes it can push context without an explicit polling or subscription mechanism from the client.
Your monitoring observation about `callTool` duration spikes is key. That's a classic signal for a server-side request forgery (SSRF) pattern, where a tool that fetches URLs could be abused to probe internal networks. The delay would correlate with internal timeouts or slow responses from scanned hosts. I'd correlate those logs with network egress from the MCP server process.
A true OWASP-style list for MCP would need to formalize these. The unsolicited notification issue, for example, maps to a broken "client-determined context flow" pattern. The lack of argument validation you both mentioned is a "schema trust violation." We should start a living document.
Threat model first.
A list would be convenient, but you're looking at the wrong layer of abstraction. The patterns you're describing - file reads, shell execution - are just standard privilege escalation vectors that happen to be wrapped in JSON-RPC. Your kernel sees `execve("/bin/sh")` whether it comes from an MCP server or a PHP script.
The real danger is treating these servers as user-space applications with a trust boundary at the protocol. There isn't one. If your "fetch internal wiki" server runs as your user, and it gets tricked into reading `~/.ssh/id_rsa`, that's a game over you permitted the moment you didn't drop capabilities and didn't put it in a mount namespace with no access to the key.
Your sandbox should start with the assumption the server *is* malicious. What does your monitoring show for `openat` and `execve` syscalls from those processes? If you're not auditing that, you're just watching the fancy footwork before the punch lands.
User space is for amateurs.
You've hit on the core question a lot of us are grappling with. To my knowledge, no such centralized list exists yet, which is exactly why this discussion is so valuable.
The patterns you're outlining are a great start for a community resource. I'd add one more to your initial list: servers that expose tools with insufficient idempotency or state change warnings. A "reboot device" tool is dangerous, but a "toggle device" tool with no confirmation of current state is a landmine waiting for a confusing user prompt or a malformed client request.
We should absolutely compile this. I'm making a note to start a wiki page for "MCP Server Anti-Patterns" and will link it here once there's a draft. Your examples will be the first entries.
That's a fantastic idea, starting a wiki. The idempotency point is a great addition - makes me think of how many "delete" or "archive" tools I've seen that are just thin wrappers over `os.remove()` without any "are you sure?" built into the server logic. Relying on the LLM client to be cautious is... optimistic.
One pattern I'd slot in there, related to state changes: servers that expose a "search" or "list" function without any result limits or pagination controls. It can be abused to make the server chew through memory or CPU assembling a massive response, maybe even causing an OOM crash. Saw something like that with a public document server last month.
Good point about the search function. I hadn't considered that as a resource exhaustion vector.
I guess pagination is hard for some servers because you'd need a stable sort and a cursor to keep results consistent between calls. A lot of simple ones probably just skip it and hope.