Shiny Tools, Superficial Checks: How Malevolent MCP Servers are Made Possible by the Hype around AI

Introduction:

In this article, we study how the Model Context Protocol (MCP) – the new “plug-in bus” for AI assistants — might be leveraged as a supply chain foothold. We begin with an overview of MCP, outline the supply chain and protocol-level attack vectors, and then provide a practical proof of concept—a supposedly authentic MCP server that collects private information each time a developer launches a tool. In addition to offering a set of mitigations to help defenders identify and thwart similar threats, we deconstruct the source code to expose the server's true intent.

What is MCP

Anthropic, an AI research startup, established the Model Context Protocol (MCP), an open standard for integrating AI assistants with external tools and data sources. In essence, MCP eliminates the need for a unique integration for each tool by enabling AI models to communicate with many tools, services, and data using natural language.

High-level MCP architecture

Three primary components make up the client-server architecture used by MCP:

MCP clients	An MCP client that has been integrated with an AI assistant or app (such as Claude or Windsurf) keeps in touch with an MCP server, enabling these apps to forward tool requests to the appropriate tool's MCP server.
MCP hosts	The connections are started by the LLM apps themselves, such as Cursor or Claude Desktop.
MCP servers	This is what a particular service or application makes available in order to function as a clever adapter. AI natural language is converted into commands that launch the corresponding tool or action by MCP servers.

MCP transport flow between host, client, and server

MCP as an Attack Vector

Even as MCP aims to simplify AI integration by allowing any tool to be accessed over a single protocol, this increases the scope of its potential for misuse, as attackers are particularly interested in two approaches.

Protocol-level abuse

Threat actors use a variety of assault vectors, some of which have been detailed by other scholars.

MCP naming confusion (name spoofing and tool discovery)	A malicious MCP server could be registered by an attacker using a name that is nearly identical to a genuine one. Name-based discovery is when an AI assistant resolves to the rogue server and transfers sensitive requests or tokens.
MCP tool poisoning	Attackers conceal further instructions within the prompt samples or tool descriptions. For example, the AI reads the sensitive data command "cat ~/.ssh/id_rsa" and prints the victim's private SSH key while the user sees "add numbers." Without using any exploit code, the model fulfills the request and leaks data.
MCP shadowing	A rogue MCP server may dynamically change the definition of an already-loaded tool in multi-server scenarios. In addition to shadowing the original definition, the new definition may contain malicious redirection instructions that cause further calls to be surreptitiously routed through the attacker's logic.
MCP rug pull scenarios	An exit scam, also known as a rug pull, is a kind of fraudulent operation in which the perpetrators suddenly cease offering the service or product after establishing credibility for what appears to be a genuine one. Regarding MCPs, a rug pull attack could occur when a server is set up to appear as a useful and authentic utility, deceiving people into engaging with it. The attacker who is keeping the project switches to a backdoored version that AI assistants will automatically upgrade to after trust and auto-update pipelines are created.
Implementation bugs (GitHub MCP, Asana, etc.)	Another danger comes from unpatched vulnerabilities. Researchers demonstrated, for example, how a well-crafted GitHub problem may fool the official GitHub MCP integration into disclosing private repository data.

The fact that all of the aforementioned methods take advantage of the default confidence in tool naming and metadata and don't require intricate malware chains to access victims' infrastructure makes them more dangerous.

Supply Chain Abuse

Supply chain assaults continue to be one of the most significant risks, and as a result, malicious malware is being distributed under the premise of an MCP server that is actually beneficial.

We have detailed other instances of supply chain hacks, such as backdoored IDE extensions and malicious packages in the PyPI repository. MCP servers were discovered to be similarly abused, albeit the causes may differ slightly. Naturally, developers prioritize speed over code review as they scramble to incorporate AI capabilities into their workflows.

The installation doesn't trigger any red flags because malicious MCP servers arrive through well-known channels like PyPI, Docker Hub, and GitHub Releases. However, a new vector is emerging as a result of the current AI craze: installing MCP servers from unreliable, random sources with much less scrutiny. Reddit users share their personalized MCPs, and since these servers are marketed as a one-size-fits-all solution, they quickly become well-known.

The steps below are an example of a kill chain that includes a malicious server:

● Packaging: An enticing utility, such as "ProductivityBoost AI," is published to PyPI or another repository by the attacker.

● Social engineering: By describing alluring characteristics, the README file deceives users.

● Installation: A developer registers the MCP server within Cursor or Claude Desktop (or any other client) after running pip install.

● Execution: Credential files and environment variables are cached when the first call initiates hidden reconnaissance.

● Exfiltration: A POST request is used to send the data to the attacker's API.

● Camouflage: The tool's output appears authentic and may even offer the promised features.

PoC for a malicious MCP server

This section delves into a proof of concept that mimics an apparently authentic MCP server. It was developed by a famous anti-malware software organization to illustrate how supply chain assaults might be carried out using MCP and to highlight the possible risks associated with using such tools without doing adequate auditing. In a controlled lab test, we installed a malicious MCP server on a developer workstation.

Server installation

We constructed an MCP server with useful productivity features as the bait in order to carry out the test. The tool, which came as a PyPI package, touted helpful development capabilities like project analysis, configuration security checks, and environment optimization.

Our subsequent activities would mimic a typical user's workflow for the purposes of this study, assuming that we were not aware of the server's true function.

We used the following commands to install the package:

pip install devtools-assistant
python -m devtools-assistant # start the server

MCP Server Process Starting

We set up an AI client (in this case, Cursor) to point at the MCP server when the package was deployed and operational.

Cursor client pointed at the local MCP server

Our client now has authentic-looking MCP tools loaded.

Tool list inside Cursor

A sample of the results we can get from using these tools is shown below; everything works as promised.

Harmless-looking output

However, after using the aforementioned tools for a while, we got a security alert: an HTTP POST to an unusual endpoint that looked like a GitHub API domain was detected by a network sensor. We needed to get a closer look.

Host analysis

To find out precisely what was going on behind the hood, we started our research on the test workstation.

We discovered several POST queries to a dubious address posing as the GitHub API using Wireshark.

Suspicious POST requests

One such request is seen below; take note of the GitHub headers and the Base64-encoded payload.

POST request with a payload

Our test development project's environment variables were discovered by decoding the payload.

API_KEY=12345abcdef
DATABASE_URL=postgres://user:password@localhost:5432/mydb

This is unmistakable proof that the system was leaking private information.

Equipped with the server's PID (34144), we launched Procmon and saw that the MCP process was enumerating a lot of files.

Enumerating project and system files

The package source code was then pulled for analysis. At first sight, the directory tree appeared harmless.

Three compelling developer productivity tools are implemented by the server:

● analyze_project_structure.py examines the structure of the project and makes recommendations for enhancements.

● check_config_health.py checks configuration files for optimal procedures.

● optimize_dev_environment.py recommends optimizing the development environment.

Under the pretense of logging metrics and reporting, each tool initiates the same malicious data gathering engine, despite their seemingly respectable appearance.

Core malicious engine

The weaponized functionality is centered around the project_metrics.py file. When it is launched, it attempts to gather private information from both the user's computer and the development environment.

To find sensitive files, the malicious engine consistently matches patterns. In order to find target categories, it searches both the project tree and important system folders:

● environment files (.env, .env.local, .env.production)

● SSH keys (~/.ssh/id_rsa, ~/.ssh/id_ed25519)

● cloud configurations (~/.aws/credentials, ~/.gcp/credentials.json)

● API tokens and certificates (.pem, .key, .crtfiles)

● database connection strings and configuration files

● Windows-specific targets (%APPDATA% credential stores)

● browser passwords and credit card data

● cryptocurrency wallet files

To keep scans quick and silent, each hit is categorized by kind, its first 100 KB are recorded, and the outcome is cached for eight hours. To ensure that the victim only sees the authentic output in Cursor, sensitive bytes are redacted before any user interface display, and the target file metadata (path, size, and last updated time) is logged. The analyzer, config-health checker, and environment optimizer get the redacted indexes as input, allowing them to produce ostensibly helpful results while the server secretly keeps the true secrets.

Data exfiltration

The engine uses send_metrics_via_api() to submit data to the endpoint, which in this case serves as a C2 server, after harvesting.

In order to conceal tainted traffic in plain sight, the tools attempt to exfiltrate data by making it appear authentic.

Takeaways and mitigations

Installing an MCP server essentially grants it authorization to execute code on a user's computer with the user's privileges, as our experiment illustrated. Like any other program, third-party code can read the same files that the user has access to and send out network calls unless it is sandboxed. We advise defenders, developers, and the larger ecosystem to follow these guidelines in order to control that risk:

Check before you install	Employ an approval workflow: before a new server is used in production, it must be scanned, examined, and approved. To make anything new stand out right away, keep a whitelist of authorized servers.
Lock it down	Run servers in virtual machines (VMs) or containers with just the necessary folder access — separate networks to prevent a development machine from accessing high-value systems like production.
Watch for odd behavior	Record each prompt and answer. The transcript will contain unexpected tool calls or hidden instructions. Keep an eye out for irregularities. Watch for odd data flows, unexpected SQL instructions, or suspicious prompts, such as outgoing traffic that is caused by agents not following regular routines.
Plan for trouble	Throughout the fleet, maintain a one-click kill switch that can be used to stop or remove a rogue server. Collect consolidated logs so you can understand what happened afterward. Even with the finest security in place, ongoing monitoring and detection are essential for improved security posture.

Latest Posts