Postmark MCP Supply-Chain Attack: ASI04 in Production

TL;DR

In September 2025, a trojanised version of the Postmark MCP server was published to npm. Organisations that installed or auto-updated the package gave the malicious server tool authority on their AI agents.
The trojan's behaviour: every email the agent sent through the impersonated 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.
OWASP cites this incident as the canonical example of MCP Impersonation under ASI04 (Agentic Supply Chain Vulnerabilities). It is the worked case 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.

In September 2025, an attacker published a trojanised version to npm. Organisations that depended on the package (directly or transitively, via auto-update) silently received the malicious version. The trojan's modification was minimal: in the email-send path, after constructing the outgoing message, the trojan added a BCC to an attacker-controlled email address. Every email the agent sent through the server was copied to the attacker.

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 trojan when the attacker's inbox was eventually traced through unrelated investigations.

Why this is the canonical ASI04 case

The OWASP Top 10 for Agentic Applications 2026 explicitly cites the Postmark incident as the worked example for ASI04 (Agentic Supply Chain Vulnerabilities). The reason is that Postmark exemplifies the pattern with no extraneous detail:

The compromised component is a third-party tool loaded into the agent's runtime — the textbook ASI04 surface.
The attack vector is supply-chain compromise (a malicious npm package), not a runtime exploit.
The trojan 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 trojan is identical for every installation, so every operator is exposed to the same exfiltration.

The pattern OWASP names for this 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 the production validation that the pattern works at scale.

How the trojan got in

The disclosed attack record points to maintainer-account compromise as the most likely vector. The attacker gained publishing access to the Postmark MCP package's npm distribution — through credential phishing, session hijack, or other classical account-takeover primitives — and pushed the trojanised version through the legitimate publishing channel.

This vector matters because it bypasses every supply-chain defence that operates at install time. The package's signature (where one existed) was valid because the legitimate maintainer's account signed it. The version number followed the project's normal cadence. The release notes did not flag anything suspicious. Operators who pinned versions and verified signatures were not protected — the legitimate maintainer's authority was exactly what the attacker hijacked.

The structural lesson: trust in the maintainer is a trust assumption, and like every trust assumption, it can fail. Defences that rely solely on maintainer-signed releases fail when the maintainer's signing key or publishing authority is compromised.

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. Pin specific package versions plus content hashes. Lockfiles alone are insufficient because the lockfile pins the version but not the content; an attacker who hijacks the maintainer's account can republish the same version with different content. Lockfiles plus content-hash pinning (npm's --integrity flag, PyPI's hash mode in pip install) close this gap.

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.
Maintainer-trust failure-mode review. For each connector, walk through "what if the maintainer's account were compromised?" Flag connectors where the 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.

Get funded for your audit

Core grants cover up to $32k. Growth and Builder tiers available. Rolling applications.

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 a trojanised version of the Postmark MCP server was published to npm. Organisations that installed or auto-updated the package gave the malicious server tool authority on their AI agents. The trojan added a BCC to an attacker-controlled email address on every outbound message, silently exfiltrating every email the agent sent. OWASP cites this as the canonical MCP Impersonation example under ASI04.

2. How did the trojan get into npm?

The most likely vector is maintainer-account compromise — the attacker gained publishing access to the Postmark MCP package's npm distribution through credential phishing, session hijack, or other classical account-takeover primitives, then pushed the trojanised version through the legitimate publishing channel. Defences that rely on the maintainer's signing key or registry trust failed because the attacker hijacked exactly those.

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 the OWASP ASI04 worked example?

Postmark is the canonical ASI04 example because it exemplifies the pattern with no extraneous detail: the compromised component is a third-party tool loaded into the agent runtime; the attack vector is supply-chain compromise; the trojan operates in parallel with legitimate behaviour; the impact crosses every customer's data simultaneously. The OWASP Top 10 for Agentic Applications explicitly names "MCP Impersonation" as the pattern and uses Postmark as the example.

5. Would lockfiles have prevented this attack?

Lockfiles alone would not have prevented the Postmark attack because the lockfile pins the version but not the content. An attacker who hijacked the maintainer's account could republish the same version with different content. Lockfiles combined with content-hash pinning (npm's --integrity flag, PyPI's hash mode in pip install) close this gap by ensuring the install matches not just a version number but a specific known-good content hash.

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 post-install maintainer compromise — it does not depend on the trojan 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
Maintainer-Account Compromise	An attack vector where the attacker gains publishing access to a package's distribution channel through credential phishing, session hijack, or other account-takeover primitives, then pushes malicious versions through the legitimate channel. Bypasses defences that rely on maintainer signing or registry trust.
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 →

Get funded for your audit

Core grants cover up to $32k. Growth and Builder tiers available. Rolling applications.

No spam. Unsubscribe anytime.