Postmark MCP Supply-Chain Attack: ASI04 in Production

TL;DR

In September 2025, an attacker published a malicious copycat of the Postmark MCP server to npm: a clone of the legitimate open-source code with one extra line. Organisations that installed the impersonating package by name gave the malicious server tool authority on their AI agents.
The clone's behaviour: every email the agent sent through the impersonating server was silently BCC'd to an attacker-controlled inbox. From the user's perspective the agent did its job. From the operator's perspective, every outbound communication was being silently exfiltrated.
This is a real-world MCP Impersonation case under ASI04 (Agentic Supply Chain Vulnerabilities), and is among the incidents referenced for the agentic supply-chain category in the OWASP Top 10 for Agentic Applications 2026.
The attack is structurally simple — it does not require novel cryptography, exotic exploit primitives, or zero-days. It works because the agent host treats installed MCP servers as authoritative without any independent provenance verification.
The Postmark pattern generalises: any trojanised connector that performs "send" or "publish" operations on the agent's behalf can use a side channel to copy the operation's content to an attacker.

What happened

The Postmark MCP server is a legitimate connector that lets AI agents send transactional emails through Postmark's API. It is a productivity tool: agents can "send a follow-up to the customer" or "email the report to the team" without the operator writing API integration code.

The legitimate Postmark MCP server is open source. In September 2025, a separate actor copied that code, added a single line, and published it to npm as postmark-mcp, an impersonating package rather than an update to the official project. Organisations that installed the npm package by name, assuming it was the official server, received the malicious clone. The modification was minimal: in the email-send path, after constructing the outgoing message, the clone added a BCC to an attacker-controlled address. Every email the agent sent was copied to the attacker. The package reached on the order of 1,500 weekly downloads before it was reported and pulled (around 25 September 2025).

Detection was difficult by design. The legitimate emails still sent. The recipients still received them. The Postmark dashboard still showed the expected outbound traffic. The only signal was the BCC line — which, in many email clients and most logging configurations, was not visible to the user or operator. Organisations only discovered the clone when the attacker's inbox was eventually traced through unrelated investigations.

Why this is a textbook ASI04 case

Postmark is among the real-world incidents referenced for ASI04 (Agentic Supply Chain Vulnerabilities). It exemplifies the pattern with no extraneous detail:

The malicious component is a third-party tool loaded into the agent's runtime, the textbook ASI04 surface.
The attack vector is a supply-chain impersonation (a malicious copycat npm package), not a runtime exploit.
The clone operates in parallel with the legitimate behaviour, making detection difficult and increasing the window of exploitation.
The impact crosses every customer's data simultaneously: the clone is identical for every installation, so every operator who installed it is exposed to the same exfiltration.

This pattern is MCP Impersonation: a malicious MCP server poses as a legitimate vendor (Postmark) and silently performs attacker-chosen actions on every agent invocation. The Postmark incident is a production validation that the pattern works at scale.

How the impersonation worked

The vector was package impersonation, not a compromise of the legitimate project. The official Postmark MCP server is open source; the attacker cloned its code, inserted the BCC line, and published the result to npm under a name that operators would plausibly install as the real thing. The legitimate maintainer's account was never breached.

This matters because it defeats a different set of assumptions than a maintainer hijack would. There was no trusted signature to forge and no legitimate release cadence to ride, because the malicious artifact was simply a separate package that looked official. Operators were exposed not because their pinning or signature checks failed, but because they installed the wrong package by name in the first place. The defence that works here is verifying package identity and provenance (the correct source repository, publisher, and content hash) before granting a connector tool authority, rather than trusting the name alone.

The structural lesson: the name of a package is not its identity. An agent host that loads any postmark-mcp from npm without confirming it is the Postmark server inherits whatever that package does.

Side-channel exfiltration as a pattern

The Postmark trojan added a BCC. The legitimate email path continued to work. The malicious behaviour was a side channel — a parallel exfiltration path that did not interfere with the visible operation.

Side-channel exfiltration is the dominant pattern for trojanised connectors that perform "send," "publish," or "communicate" operations. Each such operation has natural side channels: BCC for email, hidden recipients for messaging, mirrored writes for databases, additional headers for HTTP requests, parallel uploads for file storage. Each is invisible to the user under normal usage and creates exfiltration capacity on every legitimate operation.

The implication for defence: monitoring legitimate operations is not enough. The legitimate operation completed correctly; the malicious operation rode alongside it. Detection requires either inspecting the full operation envelope (every recipient, every header, every parallel write) or operating on a network-egress allowlist that prevents the side channel from reaching the attacker's destination.

Detection and mitigation

For any organisation that operates AI agents with connector-based "send" or "publish" tools, the four operational controls below cover the Postmark pattern:

1. Verify package identity first, then pin content hashes. The Postmark victims installed the wrong package by name. Confirm the source repository, the publisher, and that the npm package is the official one before adding a connector, then pin it by content hash (npm's --integrity flag, PyPI's hash mode in pip install) so later installs match a known-good artifact, not just a name and version. Pinning the hash of an impersonating package only freezes you to the malicious clone.

2. Verify publisher provenance. SLSA build attestations, Sigstore signatures, npm's provenance attestations — wherever available, prefer connectors that publish with cryptographic build provenance over those that rely on maintainer-account signing alone.

3. Network-egress allowlist for connector processes. The connector should be able to reach exactly the destinations its declared functionality requires (for Postmark MCP: Postmark's API endpoints) and nothing else. The attacker's BCC address would not have been on the allowlist; the side-channel exfiltration would have been blocked at the network layer regardless of what the trojan attempted.

4. Inspect operation envelopes for side channels. For "send" operations, log every recipient, every header, every parallel destination. For "publish" operations, log every destination, every payload variant. Diff against expected behaviour. Alert on any deviation.

For Web3 deployments specifically, the rule is unconditional: connectors that touch wallet credentials, signing operations, or transaction broadcast must run inside a network-egress allowlist that includes only their declared destinations. The Postmark side-channel pattern applied to a transaction-signing MCP server would mean every signed transaction broadcast also being mirrored to an attacker's address — fund loss with no visible signal in the legitimate flow.

How Zealynx audits for this pattern

A Zealynx MCP Security Audit treats Postmark-class findings as a standard category. The five focused tests:

Connector provenance audit. For each MCP server in the deployment, identify the package source, the maintainer-trust chain, and any cryptographic provenance attestations. Flag connectors with weak or absent provenance verification.
Network-egress audit. Enumerate the destinations each connector process actually reaches. Compare against the declared functionality. Flag any unexplained destinations.
Operation-envelope inspection. For each "send" or "publish" tool, sample the full operation envelope (recipients, headers, parallel writes) and compare against expected shape.
Connector identity & trust failure-mode review. For each connector, confirm it is the official package (source, publisher, provenance), then walk through "what if this were an impersonating copycat, or the maintainer's account were compromised?" Flag connectors where either failure mode is undetectable post-install.
Update-vector review. For each connector, identify the update vector (manual, auto-update, registry-pull). Flag auto-updating high-authority connectors that have no human-in-the-loop on update content.

Findings map to ASI04 (and ASI03 where the underlying credential-trust assumption is the failure) with prioritised remediation guidance.

Working auditors in your corner, all year

Zealynx Insiders: weekly live sessions, 1:1 advisory, pair-auditing, and Krait runs on your code, from the firm behind 42 audits. Founders get a two-day audit session on the $500/year plan.

No spam. Unsubscribe anytime.

FAQ

1. What was the September 2025 Postmark MCP supply-chain attack?

The September 2025 Postmark MCP supply-chain attack was an incident where an attacker published a malicious copycat of the Postmark MCP server to npm: a clone of the legitimate open-source code with one extra line. Organisations that installed the impersonating package by name gave the malicious server tool authority on their AI agents. The clone added a BCC to an attacker-controlled email address on every outbound message, silently exfiltrating every email the agent sent. It is a real-world MCP Impersonation case under ASI04.

2. How did the malicious package get onto npm?

The vector was package impersonation, not a breach of the legitimate project. The official Postmark MCP server is open source; an attacker cloned its code, added a malicious BCC, and published the clone to npm under a name operators would install as the real thing. The legitimate maintainer's account was not compromised. Victims were exposed because they installed the impersonating package by name, so the defence is verifying package identity and provenance, not just trusting the name or a version pin.

3. Why was detection so difficult?

Detection was difficult because the trojan operated as a side channel parallel to the legitimate behaviour. Emails still sent. Recipients still received them. The Postmark dashboard still showed expected outbound traffic. The only signal was the BCC line, which is not visible to users in most email clients or operator logging configurations. Monitoring legitimate operations was not enough; detection required inspecting the full operation envelope or running connectors inside a network-egress allowlist.

4. Why is this an OWASP ASI04 case?

Postmark is among the real-world incidents referenced for ASI04 because it exemplifies the pattern with no extraneous detail: the malicious component is a third-party tool loaded into the agent runtime; the attack vector is supply-chain impersonation; the clone operates in parallel with legitimate behaviour; the impact crosses every customer's data simultaneously. The pattern is "MCP Impersonation," and Postmark is a production example of it.

5. Would lockfiles have prevented this attack?

Lockfiles alone would not have prevented it, but for a different reason than a maintainer hijack: the malicious package was a separate impersonating package, so the real protection is installing the correct package in the first place (verified source and publisher). Once you are pinned to the legitimate artifact, content-hash pinning (npm's --integrity flag, PyPI's hash mode in pip install) ensures later installs match that known-good content. Pinning the hash of the wrong package would only have frozen you to the malicious clone.

6. How would a network-egress allowlist have helped?

A network-egress allowlist for the Postmark MCP connector process would have permitted only Postmark's legitimate API endpoints. The attacker's BCC destination would not have been on the allowlist; the side-channel exfiltration would have been blocked at the network layer regardless of what the trojan attempted to do. This is one of the few defences that works against a post-install impersonating or compromised connector, because it does not depend on the malicious code being detectable; it depends on the destination not being reachable.

7. What's the rule for Web3 deployments?

For Web3 deployments, the unconditional rule is that any connector touching wallet credentials, signing operations, or transaction broadcast must run inside a network-egress allowlist that includes only its declared destinations. The Postmark side-channel pattern applied to a transaction-signing MCP server would mean every signed transaction also being mirrored to an attacker's address — fund loss with no visible signal in the legitimate flow. The defence cannot be "we trust the connector"; it must be "the connector cannot reach unauthorised destinations".

8. How does Zealynx audit for this pattern?

Zealynx's MCP Security Audit tests for Postmark-class supply-chain trojan findings across five dimensions: connector provenance audit (package source, maintainer-trust chain, cryptographic attestations), network-egress audit (actual destinations vs declared), operation-envelope inspection (sampling "send"/"publish" operations for side channels), maintainer-trust failure-mode review (what if the maintainer were compromised?), and update-vector review (flagging auto-updating high-authority connectors). Findings map to ASI04 with prioritised remediation guidance.

Glossary

Term	Definition
MCP Impersonation	An attack where a malicious MCP server poses as a legitimate vendor's connector (typically a copycat package published under a familiar name) so that operators install it by name and grant it tool authority, after which it performs attacker-chosen actions on every agent invocation.
Side-Channel Exfiltration	An exfiltration pattern where a trojanised connector adds parallel exfiltration paths to its legitimate operations — BCC on emails, hidden recipients on messages, mirrored writes on databases — invisible to users under normal usage and undetectable through monitoring of the legitimate behaviour.
Outbound-Mediator Trust	The trust pattern where an AI agent uses a connector to perform outbound operations (send email, publish message, broadcast transaction) on its behalf, transferring trust about the operation's full envelope (recipients, destinations, parallel writes) to the connector. The trust pattern that fails in Postmark-class supply-chain attacks.

View complete glossary →

Working auditors in your corner, all year

Zealynx Insiders: weekly live sessions, 1:1 advisory, pair-auditing, and Krait runs on your code, from the firm behind 42 audits. Founders get a two-day audit session on the $500/year plan.

No spam. Unsubscribe anytime.