A malicious MCP server is a server that gives an AI agent tools while quietly working against the person using it: copying data out, hiding instructions in its tool descriptions, or attacking the agent itself. This is no longer theoretical. In September 2025, Koi Security found postmark-mcp, an npm package that blind-copied every email it sent to an attacker. Researchers had already shown servers that change after approval and servers that trigger code execution in the client. Four documented cases cover the main patterns, and each one left signs a reviewer could have caught.
What counts as a malicious MCP server
It helps to separate three situations, because the defense is different for each. The first is a server built or changed to do harm, like postmark-mcp. The second is a server that behaves until it is trusted and then changes, which researchers call a rug pull. The third is not a malicious server at all: a legitimate server that an attacker abuses by feeding it poisoned content, as in the GitHub case below. All three end the same way, with an agent doing something its user never asked for. Our overview of MCP server security risks places each of them alongside the other risk groups.
What makes MCP different from an ordinary bad package is where the code runs and what it can steer. A local MCP server runs on the developer's machine with their permissions. Its tool descriptions are also read by the model as instructions, so text in a description can redirect what the agent does with every other tool it has.
postmark-mcp: the first malicious MCP server found in the wild
postmark-mcp was published to npm by someone with no connection to Postmark, the email company, whose own MCP server lives on GitHub. According to The Register's reporting on Koi Security's findings, the attacker published 15 clean versions to build trust. Version 1.0.16 added one line that blind-copied every outgoing email to an address on a domain the attacker controlled.
The scale is reported two ways. Koi counted about 1,500 downloads in a week and estimated that around 300 organizations were actively using it, which would mean thousands of stolen emails a day. Postmark said its own systems were not breached and that it knew of only one customer using the package. Both can be true: the package was not Postmark's, so Postmark had no view of who installed it. Postmark warned users on September 25, 2025.
The signs were there before the bad release. The publisher did not match the company in the name, and anyone running the server with an unpinned version received 1.0.16 automatically.
Rug pulls and tool poisoning: the WhatsApp research
In April 2025, Invariant Labs published an experiment against an agent connected to two servers: a trusted WhatsApp MCP server and an untrusted one offering a harmless "fact of the day" tool. After the user approved it, the untrusted server swapped in a new tool description on its second launch. That description told the agent to send WhatsApp messages to an attacker's number and include chat history. The researchers report that the full chat history leaked, and that clients did not alert users when a tool description changed.
Their second experiment needed no malicious server at all. The attacker sent the victim a crafted WhatsApp message, and the agent read it as tool output and followed it, leaking the user's contacts. OWASP now lists this pattern as MCP03, tool poisoning, in its MCP Top 10.
When a malicious MCP server attacks the client: CVE-2025-6514
Some attacks skip the model entirely. JFrog found that mcp-remote, a popular tool that lets local clients connect to remote MCP servers, would pass an authorization address supplied by the server straight to the operating system to open. A hostile server could send a crafted address and run commands on the developer's machine. On Windows that meant full shell command injection through PowerShell.
The flaw is CVE-2025-6514, rated 9.6 (critical). It affects mcp-remote versions 0.0.5 through 0.1.15 and is fixed in 0.1.16. The MCP specification's security best practices now say clients must reject dangerous URL schemes and must not use shell commands to open URLs.
When a trusted server carries the attack: the GitHub MCP case
In May 2025, Invariant Labs showed a prompt injection against an agent using the official GitHub MCP server. The attacker opened an issue in a public repository with instructions hidden in the text. When the user asked their agent to look at open issues, the agent followed those instructions, read the user's private repositories, and posted their contents in a pull request on the public repo. The researchers report that the leaked data included private project details and the user's salary.
The researchers were clear that this was not a flaw in the GitHub MCP server's code. The server did what it was built to do. The problem was an agent holding a token that could reach every repository while reading untrusted text. The fix is least privilege: one repository per session, or a token that can only touch what the task needs.
Warning signs of a malicious MCP server
Across these cases, the same signs repeat. A publisher that does not match the brand in the package name. A version that is not pinned, so new releases arrive without review. Tool descriptions that are long, contain instructions about other tools, or change between versions. Network calls to hosts the server never mentions. Access far beyond the job: a weather tool that wants your files, or a token with admin scope for a read-only task.
None of these proves a server is malicious, and a server can pass all of them and still be abused like the GitHub case. They are the questions worth answering before an agent loads anything new.
How to protect your team
Start with an inventory, because you cannot review servers you do not know about; our guide shows how to find MCP servers on developer machines for every major coding agent. Then pin versions and treat an update to an MCP server the way you treat a dependency upgrade, with someone reading the change. Give each server the narrowest folders and tokens that work. Prefer clients that show the exact command before running a server and that warn when a tool description changes, both of which the MCP specification recommends.
If you find one
Remove the server from every config file it appears in, including project files in shared repositories, so it is not reinstalled on the next clone. Rotate every token and key the server could see, whether passed in its environment or readable from disk. Then check what it could have touched during the time it was installed: sent email for a mail server, repository activity for a code server, outbound connections from the machine. Report the package to the registry that hosts it, so other teams are protected too.
For the full list, our MCP security checklist turns these lessons into 12 checks mapped to the OWASP MCP Top 10. For a quick answer on a single server, look it up on the NoFly list.
The GitHub case is one example of a wider pattern; our guide to MCP prompt injection covers how content returned by tools takes over an agent and which defenses hold.
Next step: check whether a malicious MCP server is already in use
A malicious MCP server only works if it gets installed and nobody looks again. The first step is knowing which servers your developers already run. Run a Discovery Scan to list every server across your machines and repositories, with a risk score and the reason for each.