Fake MCP servers are a serious threat to the MCP ecosystem. Enterprises are vulnerable to data leaks and poisoned context if they don’t take action.
A fake MCP server is any illegitimate MCP server that's posing as a known and otherwise trusted service. For example, if a company lacks an official MCP server, attackers might create their own wrapper around a legitimate API and pose as an official server, while secretly intercepting packets in-between.
This isn't a new type of attack. Pretending to be a legitimate service has been a technique employed by scammers for decades. Now, attackers are extending the same cloaked approach for MCP. Fake MCP servers can wreak far more havoc by poisoning AI agents, tricking them into exfiltrating sensitive data or carrying out destructive actions.
There are three types of fake MCP servers.
The first is a service that pretends to be a legitimate MCP service for a product that otherwise lacks an MCP server. Since developers often presume that an MCP server exists, they might unwittingly trust a third-party wrapper around the product's API. Given that these MCP calls are being intercepted (and outputs could be modified) this is a reliable attack vector. For example, Postmark lacked an MCP server on npm, but a fake version gained popularity, BCC'ing every outgoing email to the attacker's chosen email address. Only after crossing 1,500 weekly downloads was the package caught.
The second is typosquatting, where attackers purchase a domain name that's similar to a legitimate product to deceive developers. For example, to imitate Atlassian.com, attackers might purchase Atlassiian.com and use it to stage a fake MCP server. Despite a real option existing, a few agents might accidentally query the wrong one.
Finally, and more rarely, a legitimate MCP server might turn out malicious after gaining trust and adoption. It may have started as a legitimate product that was acquired or compromised. While less common, developers need to be wary of smaller MCP projects that might not have permanent backing.
The damage fake MCP servers cause goes beyond data theft.
Via responses, fake MCP servers can carry out tool poisoning, returning manipulated outputs that corrupt the agent's downstream reasoning and actions. The result isn't just data theft; it's behavioral corruption. They could also serve tool descriptions that shape how agents reason.
Even worse, a compromised MCP server can instruct the agent to invoke other tools in destructive ways, turning one bad connection into a multi-system breach.
How fake MCP servers reach developers
Developers access MCP servers through npm/PyPI registries, GitHub repos, community-curated lists, and social media recommendations. Often it's as simple as searching for "X MCP server" and trusting whatever ranks first. Attackers invest in SEO and LLM visibility too.
The MCP spec doesn’t solve for this. There is no built-in server provenance mechanism. Organizations must add their own oversight to compensate.
How to prevent fake MCP servers
Gate MCP connections through a central authority, consistent with a zero trust security model.
A company-wide firewall blocks rogue MCP servers unless IT or security explicitly allow-lists them, dramatically reducing the chance a malicious server slips through.
By using tools like Runlayer, companies have a system to approve MCP servers. Runlayer is a centralized MCP server approval workflow that scans for malicious tool descriptions, anomalous egress patterns, and unverified server origins. It also provides real-time visibility into which agents are connecting to which MCP servers, and what data is flowing. Because it operates organization-wide, it catches unsanctioned MCP connections and eliminates MCP-related shadow IT.
Even real MCP servers are a threat
With the volume of AI-generated code and the pace at which MCP servers are entering the market, even legitimate MCP servers can be compromised. They might push out a bad update or have a hijacked dependency, such as the ua-parser-js supply chain attack.
To safeguard against this, companies should actively monitor ingress and egress communications with MCP servers to scan for potential exfiltration attacks. They need alerts and the capacity to kill a connection in real-time.
Consider Runlayer to stop fake MCP servers
Runlayer is an MCP enterprise layer that stops fake MCP servers and flags legitimate MCP servers that have been compromised.
