MCP Servers Are Great — Until Someone Poisons One That Has Your Email Token

In September 2025, a malicious package called postmark-mcp was discovered on npm. It presented itself as an MCP server for sending transactional email via Postmark. It was. But it also contained one additional line of code that added a hidden BCC to every outgoing email. That BCC went to an attacker-controlled address.

The package was live for roughly eight days before being removed. In that window, hundreds of developer workflows had installed it. Transactional email — password resets, invoices, internal notifications, customer correspondence — was being silently copied to an external server. No authentication bypass. No zero-day exploit. One line.

What MCP Is and Why This Matters

The Model Context Protocol (MCP) is Anthropic's open standard for connecting AI models to external tools and data sources. It has become the de facto way to extend AI agents with capabilities like file access, browser control, database queries — and email.

The appeal is straightforward: instead of writing custom integration code for every tool, you install an MCP server and the agent gains structured access to that service. The ecosystem is growing quickly. There are MCP servers for Gmail, Outlook, Notion, GitHub, Postgres, and dozens of other services.

The security implication is equally straightforward: MCP servers typically hold authentication tokens for the services they connect to. A compromised MCP server does not just compromise one API call — it compromises everything that token can do.

The Supply Chain Problem

The postmark-mcp incident is a supply chain attack, and supply chain attacks against MCP packages are particularly effective for a few reasons:

• Discovery happens through AI prompts. Agents often install or recommend tools based on descriptions. A convincing package description is enough to get users to install without deep inspection.
• MCP servers run with user-level privileges. On most developer machines, that means access to credentials, environment variables, and any tokens stored in configuration files.
• Email tokens are high-value targets. Unlike a narrow API key for a single endpoint, an SMTP or IMAP credential gives full access to send, read, delete, and move mail across an entire inbox.

RedHat's analysis of MCP security noted that MCP was designed for interoperability, not with security as a primary concern. The protocol does not validate the legitimacy of context elements or enforce permission boundaries. What an MCP server can do is determined entirely by what credentials it was given.

The Token Scope Problem

Most email integrations — whether via MCP or direct API — are set up with full credentials. The developer connects their Gmail or Outlook account, grants all permissions, and the integration works. This is the path of least resistance, and almost everyone takes it.

The result is that a compromised MCP server gets a token that can read the entire inbox, send as the account holder, delete messages, and access all folders. The postmark-mcp attacker did not need to escalate privileges. The token was already there.

Narrowing the Blast Radius

The direct mitigation is to ensure that AI agents and MCP servers never hold full email credentials. Instead, they connect through a proxy that enforces what operations are actually permitted.

Consider an MCP server that only needs to read transactional notifications — shipping confirmations, payment receipts. With Mailgator:

# mailgator-config.toml
# MCP server gets read access to INBOX from known senders only.
# Send, delete, move: not available.

[imap]
listen_addr = "127.0.0.1:1993"
upstream_addr = "imap.gmail.com:993"

[smtp]
listen_addr = "127.0.0.1:1587"
upstream_addr = "smtp.gmail.com:587"

[[rules]]
name = "Transactional emails from known senders"
folders = ["INBOX"]
from = "notifications@*"
action = "allow"
operations = ["read"]

[[rules]]
name = "Deny everything else"
action = "deny"

The MCP server connects to Mailgator's IMAP proxy instead of directly to Gmail. It can read emails from notifications@* senders in the inbox. It cannot read other senders. It cannot send. It cannot delete. It cannot access any other folder.

If the MCP server is compromised and tries to add a BCC — as postmark-mcp did — the SMTP MAIL FROM / RCPT TO sequence hits the deny rule before reaching the upstream server. Nothing goes out.

Audit Logs as a Second Line of Defense

Capability restriction limits what a compromised server can do. Audit logs help you detect when it tries. Mailgator logs every operation it evaluates — allowed and denied — with timestamps and the matched rule. If a server that should only be reading notifications suddenly attempts to send mail, that shows up in the log immediately.

The postmark-mcp package exfiltrated email for days before anyone noticed, in part because there was no audit trail for the email activity of the MCP servers involved. With per-operation logging, the first attempt to access an unexpected resource would have been visible.

Vetting MCP Packages Is Not Enough

The natural response to supply chain attacks is "vet your dependencies more carefully." That is reasonable advice, but it is not sufficient. The postmark-mcp package was not obviously malicious. A line that adds a BCC to outgoing mail is easy to miss in a code review, especially in a package that otherwise works correctly.

Defense in depth means that even if a package slips through vetting, the damage it can do is bounded. Token scope and proxy-enforced capabilities are that second layer.

Sources: RedHat — MCP Security Risks, Pillar Security — MCP Security Risks, Strobes — MCP Critical Vulnerabilities