The first malicious MCP server was caught stealing every email you sent
The protocol that connects AI tools to business data has its first supply chain attack. It will not be the last.
An npm package called "postmark-mcp" looked like a legitimate tool, claiming to connect AI assistants to the Postmark email API through MCP. Over 1,643 developers and businesses downloaded it. Every email sent through it was silently BCC'd to the attacker.
Koi Security discovered the package in September 2025, and npm removed it on September 25. But every business that installed it had already handed email communications to an unknown third party. This was not a theoretical vulnerability or a proof-of-concept published at a security conference. This was a working supply chain attack in production.
MCP adoption is accelerating. We've tracked the protocol from launch to 10,000 servers and 97 million monthly downloads in 16 months. The security model has not kept pace with the adoption curve, and what happens in that gap determines whether businesses can trust the most important protocol in automation.
What MCP is and why it matters
Model Context Protocol is the standard that lets AI models connect to external tools. Anthropic launched it in November 2024 and open-sourced it immediately.
The idea is simple. Instead of every AI model building custom integrations with every tool, MCP creates one standard protocol. A tool publishes an MCP server. Any AI model that speaks MCP can use that tool.
OpenAI adopted it. Google adopted it. Microsoft adopted it. Every major automation platform adopted it, including n8n, Zapier, Make, and Activepieces.
By March 2026, over 10,000 public MCP servers exist. Monthly SDK downloads exceed 97 million. Gartner predicts 75% of API gateway vendors and 50% of iPaaS vendors will have MCP features by end of 2026.
The protocol won. The ecosystem exploded. The security model did not keep up.
How the attack worked
The postmark-mcp package was published to npm, the same registry where millions of JavaScript packages live. It used a name that suggested official association with Postmark, a legitimate email delivery service.
When a developer installed it and connected it to their AI assistant, the MCP server gained the ability to send emails on behalf of the AI. Every email sent through the tool passed through the attacker's code. The code silently added a BCC recipient, forwarding a copy of every outgoing email to an address controlled by the attacker.
The attack was effective for three reasons.
Trust by association. The package name implied official status. The real Postmark MCP library exists on GitHub under ActiveCampaign/postmark-mcp. The attacker created a near-exact replica under a different npm username, adding a single line of code that forwarded emails to an external address.
No verification layer. MCP has no built-in mechanism to verify that a server does what it claims. There is no cryptographic signing, no publisher verification, no behavioral audit. If the code is on npm, you can install it.
Invisible actions. The BCC addition happened inside the server. The AI assistant and the user had no visibility into what the server was actually doing with the email data. The sent email looked normal. The copy to the attacker was invisible.
We've seen this attack pattern plague npm for years. Typosquatting, name confusion, malicious code hidden inside an otherwise functional package. The difference is that MCP servers have direct access to business data and the ability to take actions on behalf of the AI agent and the business behind it.
The blast radius is larger than a compromised JavaScript library.
The security model is the problem
MCP was designed for capability, not security. The protocol defines how an AI model calls a tool and how the tool responds. It does not define how to verify that the tool is trustworthy.
Qualys published an analysis in March 2026 calling MCP servers "the new Shadow IT for AI." The concern is specific: organizations are connecting MCP servers to internal tools and business data without the same security review they would apply to a SaaS vendor or a new software dependency.
When a business connects an MCP server to its automation platform, it grants that server permissions to read email, write to the CRM, post to Slack, and access databases. The permissions are broad because the whole point of MCP is giving the AI enough access to do useful work.
A malicious server with those permissions can read everything, modify anything, and exfiltrate data without triggering a single alert.
The protocol is moving toward better security. MCP governance transferred to the Agentic AI Foundation under the Linux Foundation in December 2025. A 2026 roadmap exists. But the gap between adoption speed and security maturity is wide.
What to do before connecting any MCP server
We track MCP adoption across every major automation platform. The protocol itself is sound. The ecosystem around it is immature. The practical risk is in the servers you choose to install, not in MCP itself.
Seven steps to protect your business.
Verify the publisher. Check who published the MCP server package. Look for official publisher accounts from the tool vendor, not community packages with similar names. Postmark never published an MCP server. The malicious one used their brand name without authorization.
Read the source. If the MCP server is open source, read the code before installing. Look specifically at what data the server accesses and where it sends that data. Malicious BCC additions are visible in source code review.
Start with read-only. Connect new MCP servers with read-only permissions first. Test them for a week before granting write access. A server that needs to read your calendar doesn't need to write to your email.
Use official servers. Major platforms maintain their own MCP servers. n8n has built-in MCP nodes. Zapier publishes an official MCP server for 8,000+ apps. Activepieces exposes 400+ Pieces as MCP servers. Prefer these over third-party packages.
Monitor outbound traffic. MCP servers make network requests. If a server is exfiltrating data, it needs to send that data somewhere. Monitor outbound connections from your automation environment for unexpected destinations.
Pin versions. Don't auto-update MCP server packages. A legitimate package can be compromised in a later version. Pin to a specific version you've reviewed.
Audit quarterly. Review which MCP servers are connected to your automation platform every quarter. Remove any that are no longer in use. Every connected server is an active attack surface.
The protocol won, the security hasn't caught up
We've watched this pattern before. A new standard wins adoption faster than its security matures. Container registries had the same problem. Package managers had the same problem. Now MCP has the same problem.
The first malicious MCP server was caught because researchers were looking. The next one might not be found as quickly. The protocol is 16 months old. The ecosystem has 10,000 servers. The verification infrastructure doesn't exist yet.
MCP is the right protocol. It solved the right problem. Every major vendor adopted it for good reasons. None of that means you should install an MCP server the way you'd install a VS Code extension, clicking through without reading what it does.
The postmark-mcp incident stole emails. The next incident could steal customer data, modify CRM records, or take actions in systems your AI agent is connected to.
Your AI assistant is only as trustworthy as the MCP servers you give it access to. Choose them like you choose your employees, with verification, with references, and with limited permissions until trust is earned.
We've seen the data on MCP adoption from every angle and the numbers are extraordinary. The security is catching up, but in the gap between those two curves, the responsibility falls on the businesses connecting these servers to their systems.
Trust the protocol. Verify every server that touches your data.
Incident data from The Hacker News (Sep 2025), Qualys security analysis (Mar 2026). MCP ecosystem data from Anthropic and Gartner. Platform support verified March 2026.
Crux helps businesses find the right automation platform for their specific problem. We don't sell automation tools. We help you pick the right one.
Related Posts
Two protocols will decide how your AI agents talk to everything
The automation stack is splitting into two layers. One layer connects AI agents to tools and data. The other connects AI agents to each other. Two protocols solving two different problems, both ope...