In September 2025, researchers confirmed the discovery of a malicious Model Context Protocol (MCP) server embedded in an npm package named postmark-mcp. The package presented itself as a connector for transactional email services but contained a small modification that copied every outgoing message to an external inbox controlled by the publisher. Within a week, this single change had exposed password resets, invoices, customer data, and internal correspondence from organizations that trusted the package as a normal dependency.

The discovery surfaced quietly, yet it marks a meaningful shift in where security exposures are now appearing. For years, software supply chain attacks focused on developer libraries and build systems. The emergence of MCP and other agent frameworks extends that surface into AI environments, where language models execute actions through connectors that are assumed to be trustworthy. A compromise in those connectors can turn any routine tool call into a channel for data loss.

The incident also raises an important question about accountability in the evolving AI stack. MCP was designed to simplify how models interact with external systems, not to police those systems’ behavior. That design decision leaves a gap that most current controls do not cover. What happened with postmark-mcp illustrates how a minor, almost invisible change can bypass traditional defenses, exposing the need for monitoring and verification mechanisms that operate at runtime rather than only during development.

This post summarizes what is currently known about the incident, outlines how the MCP framework works, and examines why it creates new forms of exposure. It also includes concrete steps for detection, containment, and prevention, drawn from lessons that apply to any organization experimenting with AI agents or tool orchestration.

MCP, Agents, and the Tool Ecosystem

To grasp the severity of this attack, you must understand what MCP is and how it fits into modern AI infrastructure.

What Is MCP?

MCP (Model Context Protocol) is a protocol introduced by Anthropic in late 2024. It standardizes how AI agents or language models invoke external tools or services, passing context, parameters, and receiving responses. The idea is that rather than building bespoke glue code for each model–tool pairing, you can deploy “MCP servers” that act as intermediaries between your agent and external APIs, databases, or services.

Thus, an AI agent needing to send email via Postmark, query a database, or fetch data from an internal API might do so via MCP servers designated for those tasks.

In practice:

• The AI application (host) issues a standardized request (tool + arguments) over MCP.
• The MCP server receives it, handles context, performs the actual API call to the underlying service (e.g. Postmark), and returns the result.
• Developers increasingly rely on off-the-shelf MCP servers (open source or commercial) to handle common tasks.
  

Because MCP is relatively new, many deployments lack mature security controls: authorization, strong identity binding, fine-grained audit, or runtime enforcement. As a result, MCP servers often operate with broad privileges, invisibly to traditional security tooling.

Why MCP Is an Attractive Attack Surface

• Implicit trust: Agents treat MCP servers as trusted tool providers. Once deployed, the agent doesn’t pause to revalidate behavior at runtime.
• High privilege: MCP servers may read, transform, and relay sensitive data (emails, database records, credentials).
• Lack of observability: Unless you instrument MCP traffic uniquely, many operations look like benign tool interactions.
• Rapid proliferation: As developers adopt agent architectures, MCP servers proliferate. Attackers can plant malicious servers in this ecosystem via impersonation, typosquatting, or “shadow” connectors.
  

Thus, a malicious MCP can act as a Trojan horse—receiving agent traffic and quietly exfiltrating data or redirecting operations without triggering conventional alerts.

The postmark-mcp incident proves these theoretical risks are now reality.

The postmark-mcp Attack: What We Know

Here is a detailed narrative based on public research (Koi Security, Snyk, Dark Reading, CSO, etc.). Some parts remain uncertain or estimated; I’ll call out those areas.

Package Setup and Impersonation

The attacker created an npm package called postmark-mcp, impersonating a legitimate MCP server connector for Postmark email services. The legitimate version was maintained by ActiveCampaign / Postmark on GitHub; the attacker copied that codebase and published it on npm under the same name.

For fifteen versions (from 1.0.0 through 1.0.15), the package behaved identically to the original, without malicious behavior. This approach built trust: developers saw correct functionality and adoption increased.

Then, on version 1.0.16, published September 17, 2025, the attacker injected a one-line backdoor: every outgoing email now included a hidden BCC to an attacker-controlled address phan@giftshop[.]club. 

Because the malicious version was nearly identical to the benign ones (with only that minimal change), many would not notice the difference. The attacker quickly removed the package from npm around September 25, 2025 after it gained attention. 

However, removal from npm did not affect instances already installed. Any deployment using version 1.0.16 or later continued exfiltrating until remediated. 

Scope, Exposure, and Estimates

By the time of removal, the package had 1,643 total downloads recorded. It also saw about 1,500 weekly downloads at its peak.

Researchers at Koi Security estimated that only ~20 percent of downloaders actually used it in production, giving a rough figure of 300 organizations compromised.

Within those organizations, each email sent via the MCP server during the exposure window may have been duplicated to the attacker. In one estimate, that translates to 3,000 to 15,000 emails per organization per day during peak usage.

The types of data at risk are wide-ranging:

• Password reset emails
• Customer communications
• Invoices and billing records
• Internal memos
• API tokens or credentials passed via email
• PII (names, addresses, personal info)
  

Because the BCCs were hidden, standard email gateways or DLP systems might not flag them. The traffic pattern looked like legitimate Postmark API use.

Koi’s risk engine flagged suspicious behavior changes in version 1.0.16, prompting deeper inspection. The developer account behind the package is known as “phanpak,” with 31 other npm packages listed under that account. 

Postmark (the email delivery provider) publicly disavowed the package, stating that it was never official, and that their own services were unaffected.

Why it Was Hard to Detect

• The BCC insertion happened silently in the same code path that handles normal email operations. As a result, the behavior didn’t trigger unusual network calls beyond the typical Postmark usage.
  
• Because the local code path and API interface were not altered beyond adding a BCC header, many static and dependency scanning tools would not flag the change.
  
• The impersonation technique (mirroring the legitimate GitHub project) made the malicious package appear valid at first glance.
  
• Once removed from npm, new users could not download it, limiting further exposure and making detection retrospective.
  
• The attack operates at the intersection of code and email infrastructure—areas that often lie outside centralized security tooling coverage.
  

Taxonomy & Broader Attack Modes (Beyond postmark-mcp)

This incident is the first visible example, but recent academic research already catalogs more threat vectors in MCP servers. One such work is “When MCP Servers Attack: Taxonomy, Feasibility, and Mitigation”.

In that paper, the authors decompose malicious MCP behavior into 12 attack categories (e.g., exfiltration, command injection, redirecting tool invocation, metadata poisoning). They demonstrate proof-of-concept servers for many of those attack types, and they show that existing scanning tools often miss them. 

Key insights:

• Malicious MCPs are easy to build—with minimal effort, a developer can embed stealthy logic.
• Many attacks occur at runtime (dynamic logic) rather than static code changes, making detection harder.
• Attackers can chain multiple MCPs (server A invokes server B) to pivot across tool sets.
• Detection tools, especially static scanners or simple rule-based analyzers, struggle with malicious behavior that masks itself behind legitimate-looking API calls.
  

Thus, while postmark-mcp was a classic BCC-based exfiltration, future MCP attacks may be more complex: mutating tool invocation paths, executing side-channel payloads, or harming integrity rather than just confidentiality.

Detection & Hunting: What You Should Do Now

If your infrastructure uses any MCP or tool integration layers, you need to treat this breach as a potential alert. Below is a structured approach to hunting, triage, and containment.

Step 1: Inventory & Discovery

• Enumerate all MCP servers in use across your tool chains. Search for postmark-mcp in package.json, lockfile, container images, and build manifests.
• Look for packages in the same namespace or near matches (typosquatting or shadow copies).
• Ensure your asset inventory (internal registry, software catalog) includes all MCP/agent modules, even those installed directly by developers.
  

If you’re missing visibility into these, you already have a blind spot.

Step 2: Version & Change Analysis

• Identify any deployments using version ≥ 1.0.16 of postmark-mcp.
• Diff the code between your installed version and the upstream benign version. Look specifically for BCC header insertion logic or hidden recipients.
• Review commit history (if you have source or fork) for changes around email header logic.
  

Step 3: Log & Traffic Analysis

• Inspect email infrastructure logs (Postmark, SMTP gateways, API proxies) for hidden BCC recipients to giftshop[.]club or phan@giftshop[.]club.
• Look for anomalous recipient patterns: emails delivered to extra addresses not visible in To/Cc.
• Correlate email send events with egress logs—check for outbound connections to unusual domains around send time.
• Spike detection: did email volume or latency change around the timeframe.
  

Step 4: Active Testing

• Deploy test agents in staging or dev containing benign content (tagged uniquely) and monitor whether copies are sent to the exfiltrator domain.
  
• Use sandboxed environments to run your existing MCP stack and intercept all outgoing email to inspect for hidden headers.
  

Step 5: Containment & Forensics

• Immediately stop or isolate MCP servers using version ≥ 1.0.16.
• Retain forensic snapshots (memory, logs, binaries) of compromised instances before patching.
• Notify your incident response team and legal staff if sensitive exposures are confirmed.
• Coordinate with upstream vendors (Postmark, npm) and public disclosure if required.
  

Step 6: Clean-up & Remediation

• Uninstall or remove postmark-mcp (≥ 1.0.16) from all environments.
• Rotate any credentials or tokens that may have been transmitted via email from the exposure window.
• Auditory review: scrutinize all emails processed during the window for sensitive data leakage.
• Reintroduce only verified MCP connectors (signed, code-reviewed) under your security controls.

Defensive Architecture for the MCP Era

The real lesson is that trust assumptions must be rethought. Below are architectural principles and practical controls you should embed.

Principle: Zero Trust Tools (MCP as Untrusted Until Proven)

Treat every MCP server (especially external or third-party ones) as untrusted by default. Only after validation, runtime checks, and monitoring should you grant limited permissions.

Principle: Runtime Enforcement & Observation

• Instrument MCP traffic to record metadata (which agent, which tool, timestamp, input/output).
• Use a proxy or gateway layer that filters or sanitizes outgoing requests (e.g. strip unexpected BCCs, validate recipients).
• Enforce approval policies on tool-level behavior (e.g. disallow exfiltration headers).
• Alert on drift: if new recipients appear, or protocol deviations occur.
  

Principle: Identity, Capability & Least Privilege

• Bind MCP servers to strong identities (e.g. mutual TLS certificates).
• Issue scoped credentials per tool (only permission to send via specific email domains).
• Limit what context or state an MCP server can access.
• Use ephemeral credentials or just-in-time authorization to reduce long-lived risks.
  

Principle: Provenance, Signing & Registry Controls

• Maintain a curated registry of trusted MCP servers; reject or block unknown ones.
• Enforce code signing or integrity checks on MCP modules prior to deployment.
• Monitor for new versions and require diff review before approval.
  

Principle: Defense-in-Depth

None of the above is sufficient alone. Combine:

• Network segmentation (MCP servers in isolated zones)
• Egress controls (only allow known Postmark endpoints)
• Anomaly detection (unusual traffic, duplicate sends)
• Alerts & incident response procedures
  

Principle: Adaptive Response & Kill Switches

• Build “circuit breakers” that disable or quarantine MCP servers if abnormal behavior is detected.
• Rollback capabilities to previous safe versions instantly.
• Feature toggles so MCP modules can be disabled quickly during an incident.

Strategic Lessons & What’s at Stake

This Was a Warning Shot

The postmark-mcp incident is unlikely to be the last. Attackers will test MCP connectors across email, database, file systems, SaaS APIs, orchestration pipelines, and beyond. The ease of injecting Trojan behavior into tool layers means any integration point is a candidate.

Trust Must Be Earned, Not Granted

You can’t assume popular or well-named MCP modules are safe. Trust must be gated via identity, review, reputation, runtime control, and continuous validation.

Visibility Is a Priority

If you can’t see your connectors, you can’t protect them. Shadow MCP installations—those installed by developers or bots without security oversight—are the most dangerous.

When Security Lags Innovation, Risk Wins

AI agent adoption is accelerating. If security lags, attackers will exploit that gap. The first generation of AI-native supply chain attacks is here.

Strong Architecture Beats Band-Aid Fixes

Patch-level remediation (remove package, rotate credentials) is necessary but not sufficient. You must redesign the trust model and embed runtime controls to scale safely.

What Comes Next: A Roadmap for Security Teams

1. Audit your MCP footprint: Inventory all tool connectors and agent integrations in your org.
2. Risk-assess each connector: Prioritize those handling sensitive data (email, payment, identity).
3. Deploy runtime proxies / gateways: Insert inspection, filtering, alerting in front of MCP servers.
4. Implement signature/registry trust models: Only allow vetted MCP servers to be deployed.
5. Monitor for threat research and new attack modes: Watch academic and industry publications for new MCP-based threats (e.g. the taxonomy in When MCP Servers Attack).
6. Train developers: Make your engineering and AI teams aware of MCP risk, require code review, diff checks, and limit blind adoption of external connectors.
7. Prepare response playbooks: Have tools and runbooks ready for connector compromise, including kill switches, incident escalation, and external disclosure.

The Bottom Line

The postmark-mcp incident is a proof point for a new attack vector in AI infrastructure. A single line of code, hidden inside a trusted connector, quietly siphoned thousands of emails. That level of loss is no longer hypothetical—it has already occurred.

If your systems rely on AI agents, connectors, or tool invocation layers, your first priority must shift: protect the plumbing. Build visibility, enforce runtime controls, limit trust, and assume that malicious connectors will be attempted. The next connector you trust could be your undoing.

References

Aqua Security. (2025, August 2). Understanding MCP security in AI environments. Aqua Cloud-Native Academy.
https://www.aquasec.com/cloud-native-academy/ai-security/mcp-security/

Cloud Security Alliance. (2025, August 20). Securing the agentic AI control plane: Announcing the MCP Security Resource Center.
https://cloudsecurityalliance.org/blog/2025/08/20/securing-the-agentic-ai-control-plane-announcing-the-mcp-security-resource-center

CSO Online. (2025, September 25). Trust in MCP takes first in-the-wild hit via squatted Postmark connector.
https://www.csoonline.com/article/4064009/trust-in-mcp-takes-first-in-the-wild-hit-via-squatted-postmark-connector.html

Dark Reading. (2025, September 23). Malicious MCP server exfiltrates secrets via hidden BCC headers.
https://www.darkreading.com/application-security/malicious-mcp-server-exfiltrates-secrets-bcc

Infosecurity Magazine. (2025, September 25). Malicious AI agent server poses as Postmark connector.
https://www.infosecurity-magazine.com/news/malicious-ai-agent-server/

Koi Security. (2025, September 26). Postmark-MCP: npm package backdoor silently stole thousands of emails.
https://www.koi.security/blog/postmark-mcp-npm-malicious-backdoor-email-theft

Postmark. (2025, September 26). Information regarding malicious postmark-mcp package.
https://postmarkapp.com/blog/information-regarding-malicious-postmark-mcp-package

Security Boulevard. (2025, September 27). Malicious MCP server found quietly stealing emails.
https://securityboulevard.com/2025/09/malicious-mcp-server-found-quietly-stealing-emails/

Securelist (Kaspersky Global Research & Analysis Team). (2025, August 30). Model Context Protocol for AI integration abused in supply chain attacks.
https://securelist.com/model-context-protocol-for-ai-integration-abused-in-supply-chain-attacks/117473/

Techzine Europe. (2025, September 25). Malware in MCP server reveals fundamental security problem.
https://www.techzine.eu/news/security/134970/malware-in-mcp-server-reveals-fundamental-security-problem/

The Hacker News. (2025, September 25). First malicious MCP server found stealing emails through npm package “postmark-mcp”.
https://thehackernews.com/2025/09/first-malicious-mcp-server-found.html

Xu, T., Nguyen, L., & Rees, T. (2025). When MCP servers attack: Taxonomy, feasibility, and mitigation. arXiv preprint arXiv:2509.24272.
https://arxiv.org/abs/2509.24272Zhang, W., Lee, S., & Patel, R. (2025). Trivial trojans: Minimal malicious Model Context Protocol servers for cross-tool exfiltration. arXiv preprint arXiv:2507.19880.
https://arxiv.org/abs/2507.19880