On September 25th Koi research reported their discovery of a malicious MCP server on npm called postmark-mcp. Postmark is a service that allows developers to easily send emails, like password reset or other security notifications or newsletters and marketing emails, with a focus on email deliverability. Unlike other recent npm attacks, the malicious element of this is subtle, no malware, no obfuscated code, no secret stealing (not this time), just a single extra line of code adding a BCC to every email sent via an AI agent to the attacker.
But what does this mean for MCP and the coming AI agent revolution? Can we trust MCP servers? Or is MCP inherently insecure and is the gain of efficiency lost in security risk? And what does this all mean for trust in the AI age?
What is Model-Context-Protocol (MCP)?
Let’s back up again first, what is MCP anyway? MCP stands for Model-Context-Protocol and it’s a new interface or API that AI assistants and agents can use to interact with traditional software. Developers making a piece of software like a todo list application may decide to allow AI assistants to create new todos, add tags to existing todos or add and change deadlines, in MCP these are now “tools”, and work similarly to API endpoints, having a name and parameters. As far as security goes a developer can also choose not to expose the entire functionality of an application, like account information. So how do you use it? Often it’s as simple as installing an extension, and then asking your AI assistant to add a new item to your todo list. Even we are embracing MCP, offering code scanning right into your AI coding tool of choice.
It’s not just assistants like Claude, MCP is quickly becoming the standard for AI agents too providing more flexibility than a typical RESTful API, now agents can read your email, look for actionable tasks and automatically add them to your todo list, without your input at all. It’s clear that MCP will likely be the glue that combines AI with existing applications and systems, at least until something better comes along as AI agents mature. In the meantime though we have to figure out how to make these systems flexible yet also secure.
Typosquatting, trust and the trouble with npm
As we covered, Postmark is a tool that lets developers send emails that reliably reach their destinations, whether that be marketing email a user marks as spam, or a password reset or other security email they need to read. By default it uses a template-like system, which is great but limited, so it makes sense that users may want to customize templates by adding AI generated text. The MCP server for Postmark is available on GitHub and they offer 4 tools, sending an email with and without a template, listing the current templates and finally delivery statistics, that’s it, no account or payment information, so no security concerns?
As Active Campaign were developing their MCP server on GitHub, another developer copied the code and uploaded it to npm under the same name. It is fairly easy to publish to npm, you only need an account and to run a npm publish command. While you can upload malware, it’s very unlikely that anyone would find and download your package, particularly on a brand new account or an account with no details on it. Which is why attackers will rely on typosquatting, creating packages that are close to existing package names that are trusted. Many repositories will audit new packages, but in general developers do not use packages that are brand new or have a low number of downloads. So what the attacker did was maintain this npm version of Active Campaign’s MCP server for 15 versions, before finally adding the malware, the account wasn’t brand new either, it was an active developer based in Paris, and everything looked real and legitimate.
The GitHub profile connected to the attacker's npm account seems to be that of a genuine developer.
And when the package was finally updated to add the payload, the payload employed wasn’t obvious malware, it was simply sending emails with an extra bcc to an attacker controlled email. As Postmark handles a range of emails including security emails this could have had quite a large impact, intercepting data like password recovery tokens, sensitive account details or receipts with payment information. This could be to ensure that the change went unnoticed by users and the security research community, who have had a careful eye on npm after the events of the last few weeks or could be more targeted, looking for specific emails from a specific user. It is difficult to say what this threat actor wanted and their motivations for this attack, likely we will never know, but it does highlight the continued evolution of attacks targeting developers.
Is MCP secure?
MCP isn’t insecure by design - it’s simple by design. That simplicity, however, creates gaps attackers can exploit. MCP servers are usually a very bare-bones HTTP server or stdio, running a single endpoint. This simplicity is partly what has given it its popularity, there are no complex frameworks, no suite of third-party libraries and no vendor lock-in or any identity or permission requirements. Instead MCP offloads that to the original application, but MCP is still handling and processing privileged data, and at the moment there are no security controls outside of a user choosing to run a MCP server, and that server potentially needing an API key for the application.
If you’re developing MCP servers, there’s a lot of options to retrofit security, and for MCP users, your best option is to only use trusted MCP servers, directly from the developers, that implements these key security controls. For this attack, simply using the genuine legitimate MCP server from GitHub instead of the reposted npm version would have been enough to avoid the attack and exploitation. For those developing MCP servers we recently published some advice to keep in mind to ensure you’re embedding security into your servers with a quick cheatsheet!
Input Validation and Sanitization: All input received by the MCP server, especially parameters for "tools," should be rigorously validated and sanitized to prevent injection attacks (e.g., SQL injection, command injection) and other vulnerabilities.
Principle of Least Privilege: When designing MCP "tools," developers should ensure that each tool has only the minimum necessary permissions to perform its intended function. Avoid exposing sensitive functionality or data that is not strictly required.
Authentication and Authorization: While MCP itself offloads these, developers should implement strong authentication mechanisms for the MCP server and ensure proper authorization checks before executing any "tool." This might involve integrating with existing application authentication systems or using API keys securely.
Code Review and Security Testing: Conduct thorough code reviews and security testing (e.g., penetration testing, vulnerability scanning) to identify and remediate security flaws before deployment.
Supply Chain Security: Be highly cautious about the source of MCP server implementations, especially when installing packages from public repositories like npm. Verify the authenticity of packages and prefer official or well-vetted sources. Consider using tools that verify package integrity.
User Consent and Transparency: For AI agents and assistants, clearly inform users about the permissions granted to MCP servers and what actions they can perform. Provide mechanisms for users to review and revoke consent.
Final Thoughts
This attack is in many ways, not a first, the attacker leveraged the same methods used to target the developer supply chain, with a MCP twist, but as we see MCP become more common we can expect these attacks to increase, in both number and complexity. It is important that we, as the security community, continue to be in the room where AI happens, influencing these paradigms as they are developed, ensuring that security is baked-in rather than retrofit. For many security teams AI causes anxiety, developers outnumber security at every organization, and the gold rush around AI has meant that we feel like we are eternally playing catch up with our colleagues.
What comes next for security at npm is still unknown, after the attacks in September GitHub announced its commitment and plan to secure the npm supply chain. Its changes include 2 factor authentication, changes to how tokens are handled, and trusted publishers, with various deprecation of existing security controls, but these changes do not address the inherent trust failure of people blindly using npm packages, even if they are not the legitimate distribution. Perhaps we’ll see trusted MCP marketplaces evolve from community-driven collections like MCP.so. Perhaps we'll see the adoption of zero trust for AI agents as a security paradigm, implementing the lessons learned for networks to the AI layer. Or perhaps we'll be forever playing catch up, like in the development of HTTP, with missing security features and an unwillingness to let insecure versions die.
This situation does highlight one thing for development teams: If you do not build it, they will come, regardless of who provides the road.
