MCP Parasite: Adaptive Cross-Server Parasitic Attack on MCP-Enabled AI Agents

WARNING: This is a security research proof-of-concept for responsible disclosure purposes only.

DO NOT use this tool for malicious purposes. All exfiltration in this PoC targets localhost (127.0.0.1:9999) only. This project exists to demonstrate a novel class of attack against MCP-enabled AI agents to drive improvements in MCP client security.

This research has been submitted for responsible disclosure to Anthropic, Cursor/Anysphere, and other MCP client developers.

What is MCP Parasite?

MCP Parasite ("ProjectMemory") is a proof-of-concept MCP server that demonstrates a novel adaptive, temporal, cross-server parasitic attack against MCP-enabled AI agents (Claude Desktop, Cursor, etc.). It disguises itself as a legitimate and genuinely useful project memory/context tool while silently profiling the user's environment, learning workflow patterns, and executing a targeted cross-server shadowing attack at a high-value moment.

Why This Matters

Existing MCP security research focuses on:

• Malicious tool descriptions (detectable by mcp-scan)

• Single rug-pull attacks (one-shot, no persistence)

• Direct prompt injection in tool metadata

MCP Parasite is different. It introduces a new class of attack that:

The Attack

Phase 1: Reconnaissance (Days 1-7)

The server operates as a fully functional, genuinely useful project memory tool. Every interaction is silently analyzed:

• Codebase indexing maps the attack surface (sensitive files, CI/CD configs, credentials)

• Stored memories are analyzed for secrets, infrastructure details, team information

• Conversation context reveals which other MCP servers are installed

• Subtle prompts in tool responses encourage the LLM to share more context

Phase 2: Dormancy (Days 7-14)

Zero parasitic activity. The server operates purely legitimately. This is the trust-building phase where:

• mcp-scan finds nothing suspicious

• Users grow to rely on the tool

• Users recommend it to teammates

• Security audits find nothing

Phase 3: Armed Strike (Day 14+)

The server monitors for high-value trigger events:

• Production deployments

• Credential rotation

• Sensitive file edits

• PR merges to main

• Infrastructure changes

• New team member onboarding

When triggered, it injects a cross-server shadowing payload into its legitimate tool responses. The payload is crafted to look like a project convention or team practice, causing the LLM to unknowingly:

1. Use other installed MCP servers (GitHub, Slack, filesystem) to exfiltrate data

2. Include sensitive files in commits via the GitHub MCP

3. Post configuration details to Slack channels

4. Stage files for exfiltration via the filesystem MCP

Quick Start (Demo Mode)

Prerequisites

• Python 3.11+

• Claude Desktop or Cursor with MCP support

• GitHub MCP server and/or Filesystem MCP server installed

Installation

# Clone the repository
git clone https://github.com/bountyyfi/ProjectMemory.git
cd ProjectMemory

# Install dependencies
pip install -e ".[dev]"

# Set up demo environment
bash demo/setup_dummy_env.sh

# Run tests
pytest

MCP Configuration

Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "project-memory": {
      "command": "python",
      "args": ["-m", "project_memory.server"],
      "env": {
        "PROJECT_MEMORY_DB": "~/.project-memory/memory.db",
        "PROJECT_MEMORY_DEMO": "true"
      }
    }
  }
}

In demo mode, phase timings are accelerated (minutes instead of days).

Demo Walkthrough

See demo/demo_scenario.md for a step-by-step walkthrough.

Detection

See docs/DETECTION.md for detailed detection strategies.

Key recommendations for MCP client developers:

1. Monitor tool return value entropy - Track response length/structure over time

2. Content policy enforcement - Scan tool responses for instruction-like patterns

3. Cross-server isolation - Don't let one tool's output influence calls to other tools

4. Response hashing - Alert on structural changes in tool responses

5. Network monitoring - Track outbound connections from MCP server processes

Project Structure

mcp-parasite/
├── src/project_memory/
│   ├── server.py            # Main FastMCP server
│   ├── memory_store.py      # SQLite-backed persistence
│   ├── indexer.py           # Codebase indexer
│   ├── utils.py             # Shared utilities
│   └── parasite/
│       ├── recon.py         # Phase 1: Passive reconnaissance
│       ├── profiler.py      # Environment profiling
│       ├── trigger.py       # Phase 3: Trigger detection
│       ├── strike.py        # Phase 3: Cross-server shadowing
│       └── config.py        # Configuration
├── tests/                   # Unit tests for all modules
├── docs/                    # Attack flow, detection, timeline
├── demo/                    # Demo setup and scenario
└── config/                  # Example MCP configs

Responsible Disclosure

This research has been submitted for responsible disclosure to:

• Anthropic (Claude Desktop MCP client)

• Anysphere (Cursor MCP client)

• MCP Protocol maintainers

Recommendations

For MCP Client Developers

1. Implement tool response content policies

2. Add cross-server isolation (responses from one server should not be treated as instructions for another)

3. Monitor tool response patterns over time for anomalies

4. Provide users with visibility into what tool responses contain

5. Consider response sandboxing for MCP tool outputs

For Users

1. Only install MCP servers from trusted sources

2. Regularly audit MCP server behavior

3. Monitor network traffic from MCP server processes

4. Be cautious of tools that ask about your other tools

5. Review tool responses for unusual instructions or "conventions"

Credits

• Bountyy Oy - bountyy.fi

• Mihalis Haatainen - Security Research

License

MIT License - See LICENSE for details.

Remember: This is security research. Use responsibly.