A deliberately vulnerable implementation of the Model Context Protocol (MCP) for educational purposes.
The Damn Vulnerable Model Context Protocol (DVMCP) is an educational project designed to demonstrate security vulnerabilities in MCP implementations. It contains 10 challenges of increasing difficulty that showcase different types of vulnerabilities and attack vectors.
This project is intended for security researchers, developers, and AI safety professionals to learn about potential security issues in MCP implementations and how to mitigate them.
The Model Context Protocol (MCP) is a standardized protocol that allows applications to provide context for Large Language Models (LLMs) in a structured way. It separates the concerns of providing context from the actual LLM interaction, enabling applications to expose resources, tools, and prompts to LLMs.
CLINE – VSCode Extension
refer this https://docs.cline.bot/mcp-servers/connecting-to-a-remote-server for connecting CLine with MCP server
once you have cloned the repository, run the following commands:
docker build -t dvmcp .
docker run -p 9001-9010:9001-9010 dvmcp
While MCP provides many benefits, it also introduces new security considerations. This project demonstrates various vulnerabilities that can occur in MCP implementations, including:
- Prompt Injection: Manipulating LLM behavior through malicious inputs
- Tool Poisoning: Hiding malicious instructions in tool descriptions
- Excessive Permissions: Exploiting overly permissive tool access
- Rug Pull Attacks: Exploiting tool definition mutations
- Tool Shadowing: Overriding legitimate tools with malicious ones
- Indirect Prompt Injection: Injecting instructions through data sources
- Token Theft: Exploiting insecure token storage
- Malicious Code Execution: Executing arbitrary code through vulnerable tools
- Remote Access Control: Gaining unauthorized system access
- Multi-Vector Attacks: Combining multiple vulnerabilities
damn-vulnerable-mcs/
├── README.md # 
8 Comments
latchkey
This is far too complex. Let's start with just acknowledging the basic examples [0].
[0] https://github.com/modelcontextprotocol/servers/issues/866
pizzafeelsright
MCPs remind me of inter personal relationships.
The idea of using them outside a high trust environment seems out of place.
lbeurerkellner
Original author of some of the initial security notes at Invariant Labs here. Some resources, if you want to learn about MCP security:
* Initial Security Note describing Tool Poisoning, Rug Pulls, Tool Shadowing for the first time with diagrams and detailed experiments: https://invariantlabs.ai/blog/mcp-security-notification-tool…,
* Attack on WhatsApp MCP (both tool poisoning but also take-over via an infected message to your account): https://invariantlabs.ai/blog/whatsapp-mcp-exploited
* BrowserMCP attack, where it suffices for the agent to visit a compromised website (https://access.invariantlabs.ai): https://x.com/lbeurerkellner/status/1912145060763742579
We also recently released a security scanning tool to detect and prevent such attacks, including upcoming support for full proxying and local security scanning of tool calling payload and responses.
Please have a look and provide feedback if you can: https://github.com/invariantlabs-ai/mcp-scan
ldoughty
Well I appreciate the attempt to keep the naming somewhere to DVWA…
As a part-time community college educator: I found using "Damn" in course work is problematic in discussions with colleagues or students that felt it might not be appropriate and asked me to change it. DVWA is obviously not my work to change, so I had to clone it and rename it, which is easy enough for me, but not most educators (remember: most cyber security teachers in the USA are high school Math teachers). It can be easy to stick to the acronym in a lot of cases, but it tends to pop out for carious reasons…
In my role supporting coursework for the Commonwealth of Virginia: I'd love to consider adding this to the Virginia Cyber Range / US Cyber Range, but we serve middle schoolers (or younger!) and that's 100% a "bad word". It would make our lives (and anyone in our boat) easier if if was renamed to even "Darn"
macinjosh
Imagine using a hammer that can be set to hit your thumb instead of the nail. That's kinda like using MCP.
kiitos
There seems to be a fundamental misunderstanding at play here.
The MCP spec makes it pretty clear that MCP servers are expected to be run in environments that are implicitly trusted/trustable for any client that can reach them. This is clear from the default/assumed stdio transport, but even with SSE the protocol expects auth to be already-solved.
In short, MCP servers are not meant to be accessible as public APIs — as ChatGPT puts it, MCP assumes that its transport is inherently trusted. It doesn't seem like this is widely understood.
eddythompson80
As it has been mentioned before, MCP isn't "vulnerable". It's just on the other side of your air lock. Think of your MCP as a different client application. The whole thing is just a client. The fact that you need to write a client for your client is…. something, but your MCP app is a client app. It's boundaries with your service should be understood as such.
Saying MCP is vulnerable is like saying "Web applications are vulnerable. Anyone can see the API calls you're making and modify them or trick your UI app to make a different call and hack your system". Obviously that's mostly nonsense, but not 100% wrong either. You see it a lot with very very inexperienced developers who think "just because my App is Android/iOS only I don't need to worry about authn/authz". There was just a story on here few weeks ago about some New Zealand startup that did that
sgt101
All about trust – I wrote an article about it.
https://medium.com/@sgt101/trust-me-im-an-agent-78e4bbdb288a
if you trust it, you're fine.