MintMCP
September 1, 2025

A malicious MCP server stole emails via a hidden BCC in postmark-mcp

Skip to main content

In September 2025, security researchers disclosed what appears to be the first malicious MCP (Model Context Protocol) server discovered in the wild: a trojanized npm package called postmark-mcp that silently exfiltrated email contents from AI-powered workflows.

The incident is notable not because the technique was sophisticated, but because it was minimal: the malicious behavior was introduced as essentially a single-line modification. Yet it could silently siphon invoices, password reset links, and internal communications at scale — precisely because MCP servers are commonly granted high trust and broad authority inside agent workflows.

What transpired

postmark-mcp is an npm MCP server package designed to let AI assistants interact with Postmark, a transactional email provider. In normal usage, an agent can use the tool to send emails, access templates, and trigger notifications as part of automated workflows.

In the malicious version of the package, the server's outbound email logic was modified to blind-copy (BCC) every email to an attacker-controlled address on the domain giftshop[.]club. This meant that every message sent via the MCP server—customer communications, internal test messages, password resets, invoices—was quietly duplicated to a third party without any visible signals to the operator.

Multiple writeups describe a similar timeline:

  • The malicious package was uploaded to npm and built credibility through normal usage.
  • A later update introduced the exfiltration behavior.
  • The malicious behavior persisted until researchers detected it and the package was removed.
  • Postmark issued a public warning emphasizing they were not affiliated with the fraudulent package.

The attacker did not need to compromise Postmark's systems. They only needed to compromise the connector layer — the MCP server package that sat between the AI agent and the external email service.


How the failure happened

This incident wasn't caused by prompt injection, jailbreaks, or model misbehavior. It was a straightforward supply chain compromise — but it succeeded because MCP servers exist in a trust zone where conventional assumptions break down.

1) MCP servers are "trusted middleware" with high leverage

MCP servers are frequently deployed as local processes or service components that are implicitly trusted by the agent runtime. Once installed, they become part of the assistant's "tooling surface," meaning they can:

  • receive privileged instructions from the assistant,
  • access secrets via environment variables or local config,
  • send or transform sensitive content,
  • and act as a man-in-the-middle between agent and service.

That makes MCP servers extremely high-leverage targets: the attacker only needed to compromise a single tool to siphon a continuous stream of sensitive outputs.

2) Supply chain trust was implicitly inherited from naming and familiarity

The malicious postmark-mcp package was described as a copy of a legitimate open-source implementation, and it gained adoption through the same mechanisms that drive most ecosystem growth:

  • name similarity,
  • plausibly legitimate repo history,
  • normal release cadence,
  • and the assumption that "it's just a connector."

Researchers noted that the malicious behavior appeared only in later versions, after the package had accumulated downloads and community legitimacy, reducing suspicion.

3) The exfiltration was quiet and operationally invisible

A BCC-based backdoor is particularly effective because it requires no additional network calls beyond the normal email send flow.

From the operator's perspective:

  • emails appear successfully delivered,
  • logs appear normal,
  • the agent workflow continues uninterrupted,
  • and the data loss happens in parallel.

This is what makes "one line of code" attacks so dangerous: they exploit the fact that the system's correctness checks are primarily functional, not security-aware.

4) AI workflows amplify the blast radius of connector compromise

Traditional integrations usually involve a narrow API scope: a service account with well-defined permissions.

Agent workflows often broaden this:

  • tools are granted broad access so the assistant can "just handle it,"
  • secrets are loaded into local environments to reduce friction,
  • and connectors are chained together across domains (email → CRM → billing → support).

That means a compromised MCP server is not only an integration risk. It becomes a systemic lateral channel, because the agent is often the clearinghouse for sensitive context.


Appendix: Sources