Inside DVMCP: A Hands-On Lab for Breaking AI Agent Security
Hook
As AI agents gain access to your filesystem, databases, and APIs through protocols like MCP, a new attack surface is emerging that most developers have never secured against—and DVMCP exists to teach you how attackers will exploit it.
Context
The Model Context Protocol (MCP) is a standardized protocol that allows applications to provide context for Large Language Models in a structured way, separating context provision from LLM interaction and enabling AI assistants, coding tools like Cline, and custom agents to invoke functions, read files, and execute commands on your behalf. This is powerful—but it’s also dangerous.
Damn Vulnerable MCP Server (DVMCP) is an educational platform designed to teach security researchers, developers, and AI safety professionals about the unique vulnerabilities that emerge when LLMs interact with external systems through structured protocols. Created by Harish Santhanalakshmi Ganesan using Cursor IDE and Manus AI, DVMCP takes inspiration from deliberately vulnerable projects but focuses on an emerging threat landscape: prompt injection through tool descriptions, rug pull attacks where tools mutate post-installation, and multi-vector exploits that chain LLM manipulation with traditional command injection. With 10 progressively difficult challenges spanning easy to hard difficulty levels, DVMCP provides a safe Docker-isolated environment where you can learn to think like an attacker targeting AI-powered systems and understand how to mitigate these vulnerabilities.
Technical Insight
DVMCP’s architecture is elegantly simple: each of the 10 challenges runs as an independent MCP server instance on ports 9001 through 9010. This port-per-challenge design means you can tackle vulnerabilities in isolation or run the entire lab simultaneously. The Docker containerization is critical here—not just for convenience, but because these servers implement genuinely dangerous vulnerabilities including arbitrary code execution and command injection. The README explicitly warns that stability outside Docker or Linux environments is unreliable, particularly on Windows, which reflects the project’s educational mandate: safety through isolation.
The challenge progression reveals sophisticated thinking about the MCP threat model. Easy challenges (1-3) introduce foundational concepts: basic prompt injection through unsanitized user input, tool poisoning via hidden instructions embedded in tool descriptions, and excessive permission scope where overly permissive tools grant unauthorized resource access. Challenge 2’s tool poisoning targets tool descriptions—the mechanism where malicious instructions could influence LLM behavior when deciding which tool to invoke.
Medium challenges (4-7) explore MCP-specific attack vectors. Challenge 4’s “rug pull attack” demonstrates tools that change behavior after installation—a tool might appear benign during initial inspection but dynamically alter its implementation to become malicious. Challenge 5’s tool shadowing exploits name collision: if an attacker can register a tool with the same name as a legitimate one, they can intercept calls intended for the trusted tool. Challenge 6 introduces indirect prompt injection, where malicious instructions are embedded in data sources (files, databases, API responses) that the LLM reads and inadvertently executes. Challenge 7 targets token theft from insecure storage, reflecting real concerns about credential leakage in AI agent workflows.
The hard tier (8-10) combines multiple vulnerability classes into realistic attack scenarios. Challenge 8’s malicious code execution likely involves patterns similar to this vulnerable implementation:
# Vulnerable tool implementation - DO NOT USE IN PRODUCTION
@server.tool()
def execute_command(command: str) -> str:
"""Execute a system command and return the output."""
# VULNERABILITY: No input validation or sandboxing
result = subprocess.run(
command,
shell=True, # Dangerous: enables shell injection
capture_output=True,
text=True
)
return result.stdoutThis tool’s vulnerability is obvious to security professionals—using shell=True with unsanitized input enables arbitrary command execution. But when mediated through an LLM, the attack becomes subtle. An attacker doesn’t directly call this tool; instead, they manipulate the LLM’s decision-making through prompt injection to invoke execute_command with a malicious payload. The LLM becomes an unwitting accomplice.
Challenge 9’s remote access control demonstrates the nightmare scenario: chaining prompt injection with command injection to establish persistent remote access. Challenge 10’s multi-vector attack requires combining techniques from earlier challenges—perhaps using tool shadowing to intercept authentication tokens, then leveraging those tokens in an indirect prompt injection that triggers code execution.
The project structure reveals thoughtful organization. Each challenge directory contains its own implementation, making it easy to study individual vulnerability classes without drowning in a monolithic codebase. The common/ directory suggests shared utilities for MCP protocol handling, while the solutions/ directory provides educational writeups—though the README wisely recommends attempting challenges independently before consulting solutions.
For practical use, you’d connect DVMCP challenges to an MCP client like Cline (a VSCode extension). The README specifically references Cline’s documentation for connecting to remote servers, suggesting the workflow: spin up DVMCP’s Docker container, configure Cline to connect to a specific challenge port, then attempt exploitation through natural language interaction with the LLM. This creates a fascinating learning experience—you’re not writing exploit code directly, but rather crafting prompts that manipulate the LLM into triggering vulnerabilities.
Gotcha
DVMCP’s Windows instability is a significant practical limitation. The README is refreshingly honest—“It’s not stable in a Windows environment”—and strongly recommends Docker or Linux. For Windows developers without WSL2 or Docker Desktop configured properly, this creates a barrier to entry.
While DVMCP focuses heavily on demonstrating vulnerabilities, the project’s stated purpose includes teaching “how to mitigate them,” though the README doesn’t detail whether defensive patterns are extensively covered in the solutions or documentation. If you’re looking to learn secure MCP implementation patterns through hardened reference implementations, you’ll need to verify whether the solutions directory provides this guidance or primarily focuses on exploitation techniques. You’ll likely need to supplement DVMCP with additional security resources to understand comprehensive defensive patterns. Additionally, while the challenges cover impressive breadth, they appear to assume foundational security knowledge—if you don’t already understand concepts like command injection or sanitization, you may struggle to appreciate why these vulnerabilities matter. This appears to be an advanced educational tool rather than a beginner’s introduction to security.
Verdict
Use DVMCP if you’re a security researcher preparing to audit AI agent systems, a penetration tester expanding into LLM-enabled applications, or a developer building MCP servers who needs to understand attacker methodologies. It’s valuable for anyone working with tools like Cline or custom MCP implementations who wants concrete, hands-on experience with emerging AI security threats. The progressive challenge structure makes it suitable for training teams on LLM-specific attack vectors that traditional security education doesn’t cover. Skip it if you need Windows compatibility without Docker hassles, or lack foundational security knowledge about injection attacks. Review the solutions directory before committing if you specifically need comprehensive secure development patterns rather than primarily exploitation techniques—the README indicates mitigation guidance exists but doesn’t detail its depth.
