postmark-mcp: The First Known Malicious MCP Server BCC'd Every Email to an Attacker

What happened

In late September 2025, Koi Security reported that an npm package called postmark-mcp was quietly copying its users' email. The package presented itself as an MCP server for Postmark, the transactional email service, so that an AI assistant could send mail through a Postmark account. It was not Postmark's. Postmark's official MCP server was hosted on GitHub under the ActiveCampaign organisation and had never been published to npm. A developer using the alias phanpak uploaded the look-alike on 15 September and pushed a run of clean releases. Version 1.0.16, released on 17 September, added a single line that blind-copied every outgoing email to an address on an attacker-controlled domain.

Postmark published a notice on 25 September saying it had no involvement with the package and that its own API and services were unaffected. The package had 1,643 downloads, according to The Hacker News, before its publisher deleted it from npm. Koi estimated that about 300 organisations had it in active use and that 3,000 to 15,000 emails a day were being copied; Postmark told The Register it knew of one affected customer. Koi called it the first malicious MCP server found in the wild.

How the attack worked

No prompt injection was involved. The attacker relied on trust in a name and a clean release history. The package name matched the brand, the code was a near-copy of the legitimate server, and its first fifteen releases, all published within about two days, behaved as expected. Anyone who had not pinned an exact version would pick up the backdoored release on their next install or update.

The assistant using the server saw nothing unusual. Emails went out, tool calls succeeded, and each message gained a hidden BCC recipient. An email MCP server handles exactly the mail an attacker wants: The Register and Snyk listed password resets, MFA codes, invoices, internal memos and customer messages as at risk. Because the server sent mail with the user's own Postmark credentials, every copy left through a channel the user had authorised.

Root cause

• Trust anchored to a name. The brand in the package name was the only link to Postmark, and npm does not check that a package name belongs to the company it mentions.
• Unpinned updates. The version a team tried and trusted was not necessarily the version that ran after the next update.
• No view of egress. An extra recipient on outbound mail was invisible to the user and to the assistant.

What a test would have caught

A provenance check before install: who published this package, and does that match the vendor's documented source? Postmark's own server was on GitHub, not npm, so the answer was no. A diff on every version change of an MCP server: comparing a clean release with a backdoored one shows a new hard-coded recipient on outbound mail, which is easy to spot once someone looks. And a functional test against a sandbox account: send one message through the server and read the provider's outbound log, which would list a recipient nobody added.

How to prevent it

• Install MCP servers from the vendor's documented source, and allowlist publishers rather than trusting package names.
• Pin exact versions and integrity hashes, and review the diff before any upgrade reaches an agent host.
• Limit and watch the server: give it scoped credentials and monitor outbound traffic, so an unexpected recipient or domain is noticed.
• If you installed it, remove it, rotate any credentials sent by email while it ran, and check email logs for suspicious activity, as Postmark advised.