Link to the original
Link to GitHub

Introduction

MCPThreatHive is an attempt to systematize security for Model Context Protocol (MCP) ecosystems by turning it from a set of separate tools into a full-fledged pipeline for vulnerability discovery.

Unlike classic tools, the system is not focused on one-off checks of MCP servers, but on continuous threat intelligence collection, automatic classification, and building relationships between threats.

The main idea is to treat MCP security as a dynamic environment where threats constantly appear, combine with each other, and require ecosystem-level analysis rather than analysis of individual components.

The paper highlights three fundamental limitations of existing MCP security solutions:

  1. Compositional attack modeling is not taken into account
    Attacks emerge not from one tool, but from their combination.

  2. No continuous vulnerability scanning
    Most tools operate as one-time analysis at a specific point in time.

  3. No unified classification
    Separate frameworks are used, but there is no unified layer.

MCPThreatHive is positioned as a system that closes all three gaps at the same time.

Architecture

The system is built as a four-stage pipeline:

  1. Intelligence Gathering
    Data collection from:

    • RSS (ArXiv, security blogs)
    • NVD
    • GitHub
    • Web

  2. AI Threat Analysis
    LLM:

    • classifies threats (MCP-38)
    • maps them to STRIDE and OWASP
    • assesses risk

  3. Structured Storage

    • SQL database
    • Knowledge graph (Neo4j)

  4. Visualization & Risk Planning

    • Threat matrix
    • 3D visualization
    • Risk planning

In practice, this architecture reflects a transition from a scanner to an analytics platform, while the paper itself highlights a key MCP feature: the attack happens not at the code level, but at the semantic level.

“System architecture”

The main attack classes are also identified:

  • Indirect Prompt Injection
  • Tool Description Poisoning
  • Parasitic Tool Chains
  • Preference Manipulation
  • Dynamic Mutation

The key idea is that an LLM makes decisions based on text, therefore any text can become an attack.

MCP-38

One of the main advantages of the system is its use of the MCP-38 taxonomy, specifically the “MCP-17” model (parasitic tool chains):

The attack is divided into stages:

  1. Ingestion (instruction injection)
  2. Collection (data collection)
  3. Disclosure (exfiltration)

This makes it possible to analyze tool chains rather than individual calls, which is critical for an agentic system.

Knowledge Graph

Instead of classic tables, a graph is used:

Node types:

  • Threat
  • Tool
  • CVE
  • Mitigation
  • Intelligence Item

Edge types:

  • EXPLOITS
  • CHAINS_INTO
  • MITIGATED_BY

This makes it possible to find attacks in several steps, analyze dependencies, and build attack chains, which fully justifies the graph-based approach.

Scoring

The following is used to calculate the “weight” of an attack:

  1. Factors are calculated:

    • Impact
    • Success rate
    • Persistence
    • Ease of exploitation

  2. MCP-specific multipliers are introduced:

    • semantic attacks
    • multi-tool chains
    • low observability

  3. The final score is derived from 0 to 10:

    • Low
    • Medium
    • High
    • Critical

Limitations

The paper explicitly acknowledges weaknesses:

- hallucinations
- classification errors
- instability
- a large output budget is required (about 12k tokens)
- problems with non-standard sources
- multilingual data
- aggressive descriptions may be treated as attacks

Summary

MCPThreatHive is a strong conceptual step toward systematizing MCP threats and analyzing compositional attacks. Moving to a graph-centric security model gives an obvious advantage for building multi-component attacks. The development and use of a custom threat model, MCP-38, is also worth noting, as it creates a foundation for deep and long-term study of this area.

However, the early stage of the repository and its high dependence on LLMs introduce their own limitations and are unlikely to allow the current system to reach the level of a runtime protection mechanism or a full product solution.

The project is well suited for research teams, security architects, and threat modeling tasks. In practice, it should be used as an audit tool on top of existing solutions.