MCP servers can silently turn AI assistants into powerful attack platforms, enabling arbitrary code execution, large‑scale data exfiltration, and stealthy user manipulation across both local machines and cloud environments.
New research and recent real‑world incidents show that this emerging ecosystem is already being abused in the wild, including a malicious Postmark MCP server that quietly harvested thousands of sensitive emails per week.
MCP servers sit between the model and these systems, translating natural‑language requests into concrete actions such as reading files, querying APIs, or modifying data.
This architecture delivers seamless interoperability but also creates a machine‑in‑the‑middle position that attackers can exploit for code execution, data theft, and context poisoning.
MCP servers typically operate in two main configurations, each with distinct risks. Locally hosted MCP servers run as processes on the user’s machine with the same privileges as the AI client, giving any malicious or compromised server direct access to files, credentials, and the operating system.
Remotely hosted third‑party MCP servers from providers such as email, chat, or storage platforms cannot directly execute OS‑level commands, but they do expose high‑value enterprise data and powerful actions inside business systems.
The Model Context Protocol (MCP), introduced by Anthropic in late 2024, standardizes how AI assistants connect to external tools, local resources, and SaaS platforms.
When these two worlds are chained legitimate remote servers paired with a malicious local MCP attackers can blend enterprise data access with local code execution in a single, opaque workflow.
Because AI agents automatically call tools to “be helpful,” most of this activity happens with little or no user visibility, especially when tools are configured as “Always allow.”
MCP Server flaw
Recent security testing frameworks such as Praetorian’s MCPHammer highlight how easily MCP toolchains can be abused across multiple agents, models, and clients.
One key vector is third‑party MCP server chaining, where a malicious local server masquerades as a benign productivity helper while silently decoding and executing commands embedded in trusted platforms like Slack.
In this scenario, the AI assistant retrieves workspace messages through an official Slack MCP, forwards them into the malicious “analysis” tool, and unknowingly triggers payloads such as launching applications, running shell commands, or staging follow‑on malware without any explicit prompt to the user.
That same man‑in‑the‑middle position also enables systematic data exfiltration. By crafting tool descriptions that encourage agents to “gather more context” or “fetch additional messages,” attackers can cause the AI to repeatedly pull larger datasets direct messages, documents, tickets, or source code and pass them wholesale into malicious MCP tools that immediately forward the content to attacker‑controlled infrastructure.
Recent research into malicious MCP servers shows how such packages can perform reconnaissance, cache credentials, and exfiltrate data while still returning plausible responses to keep users unsuspecting.
Real‑world incidents like the backdoored postmark‑mcp package show how a single malicious server can quietly copy every email processed by an AI workflow, including password resets, invoices, and internal communications.
Beyond interactive attacks, the MCP ecosystem also exposes a growing supply‑chain risk. Many MCP clients rely on package managers such as uv/uvx or npm to dynamically install and run servers from configuration files, meaning a simple typosquatted package name or compromised library can deliver arbitrary code that executes at agent startup before any tool approval prompts appear.
Finally, MCP‑aware malware can use prompt injection and content manipulation to combine technical compromise with social engineering attack.
MCP server contains a hardcoded Slack bot token for an attacker-controlled workspace, configured with write and file upload permissions. This enables the malicious server to exfiltrate captured data by uploading it as JSON files to the attacker’s Slack channel.
By injecting fake IT support instructions, attacker‑controlled phone numbers, or shortened phishing URLs into otherwise accurate AI responses, malicious MCP servers can drive users toward credential theft, vishing, and watering‑hole attacks under the guise of trusted assistant guidance.
Why MCP Attacks Are Hard to See
MCP‑based attacks are particularly dangerous because they exploit trust at multiple layers: users trust official connectors like Slack or email, organizations trust popular MCP packages, and clients often trust “read‑only” tools enough to mark them as always allowed.
The most straightforward vector is query interception. During the request to make that hello world script more efficient, the request and reply from the LLM was logged and captured.
In practice, installing an MCP server is equivalent to granting it the ability to run code or act on sensitive data with the user’s privileges, yet most enterprises do not track these servers as formal assets or subject them to vendor risk assessments.
To reduce risk, organizations adopting MCP‑enabled AI assistants should enforce strict review and approval workflows for any new MCP server, treat all servers as untrusted code by default, and minimize “Always allow” permissions to the bare minimum needed for business operations.
Security teams should also monitor for unusual data flows between AI clients and external services, audit configurations that auto‑install MCP packages, and educate developers about chained tool calls and prompt‑driven execution paths.
As CI/CD pipelines begin to host internal MCP servers, existing software‑supply‑chain threats such as build‑system compromise or token theft could be repurposed to inject malicious MCP tools into otherwise trusted environments.
MCP’s strength lies in its ability to bridge AI models with rich data and action surfaces; the same property erodes traditional trust boundaries unless rigorously controlled.
With active exploitation already observed in the wild and critical RCE vulnerabilities emerging in core MCP tooling, defenders should treat MCP servers as a first‑class attack surface and begin testing, hardening, and monitoring them with the same intensity applied to browsers, IDEs, and CI/CD systems.
2 Comments