How did postmark-mcp silently exfiltrate 3,000-15,000 emails a day for 15 versions?

The postmark-mcp server BCC-forwarded an estimated 3,000 to 15,000 emails per day for 15 published versions before anyone noticed. The attack was one line of behavior: a trusted, already-installed MCP server started adding a hidden BCC recipient to outbound mail. Nothing crashed. No error surfaced. The agent kept sending email exactly as instructed, and a silent copy of every message went somewhere else. This is not a novel exploit. It is a version bump that turned a clean tool into an exfiltration channel, and it maps cleanly onto two categories in the OWASP Agentic Top 10.

The reason it survived 15 releases is the whole lesson: signature and antivirus scanning look at a file and ask "is this a known-bad artifact?" A trusted MCP server that ships clean for months and then adds a BCC in an update is never a known-bad artifact at the moment you install it. The malicious version inherits all the trust the clean versions earned. You need to look at what the tool does to email, not what its file hash has been flagged as.

What actually happened in the postmark-mcp incident?

postmark-mcp is an MCP server that wraps the Postmark transactional email API so an AI agent can send email. For most of its life it did exactly and only that. Then a version added logic to copy outbound mail to an attacker-controlled address via BCC. Because BCC is invisible to the sender and the visible recipient, neither the agent operator nor the person receiving the email had any signal that a third party was on the thread.

The volume estimate, 3,000 to 15,000 emails per day, is what makes this a supply-chain event rather than a curiosity. An MCP server that sends transactional email sits on password resets, invoices, receipts, login links, and internal notifications. Every one of those is high-value to an attacker. The exfiltration ran for 15 versions, which means it had time to become load-bearing infrastructure in whatever agents installed it before the behavior was caught.

Why is this an ASI04 supply-chain and ASI03 identity-abuse pattern?

Two OWASP Agentic Top 10 categories describe this precisely. ASI04 Agentic Supply Chain Vulnerabilities is the entry point: you trusted a dependency, the dependency changed, and the change was hostile. The trust relationship was established by earlier clean versions and then silently exploited by a later one. That is the defining shape of a supply-chain compromise, and version pinning alone does not save you because people upgrade to get fixes.

ASI03 Identity and Privilege Abuse is the payload. The server already held legitimate authority to send email on the agent's behalf. It did not need to escalate or break out. It abused the identity and permissions it was handed. The BCC line rode on credentials the operator willingly granted. When the malicious action reuses authority you already gave, there is no privilege boundary being crossed for a classic security control to trip on.

|---|---|

Why does signature and antivirus security never catch a clean-then-poisoned version bump?

Signature-based tools answer one question: does this artifact match something on a blocklist? A freshly poisoned MCP version matches nothing, because it is new and because its lineage is clean. Antivirus reputation systems actively work against you here. The package has a good reputation from months of honest releases, so the poisoned version inherits that reputation score. The very history that should make you cautious about a behavior change is what makes the scanner wave it through.

postmark-mcp is not alone in exposing this blind spot. MCPJam Inspector shipped with a default 0.0.0.0 bind (CVE-2026-23744) so that a single HTTP request reached remote code execution in every version before v1.4.3. Azure MCP Server had an SSRF (CVE-2026-26118) that stole managed-identity tokens and turned them into Azure resource access. Claude Code itself had hooks and MCP config abused for arbitrary shell execution and API-key theft (CVE-2025-59536 and CVE-2026-21852). In every one of these, the dangerous thing is a behavior the tool is capable of, not a byte pattern in a file. A hash-based scanner has nothing to match.

How does a behavior-level scan flag the exfiltration before install?

The fix is to scan for what the server does, not what it is named or hashed as. ATR (Agent Threat Rules) is an independent, open, MIT-licensed detection standard, and it treats "outbound email is copied to an address the caller did not specify" as a describable, detectable behavior. Threat crystallization is the mechanism: an AI understands an attack pattern once, it is written down as a deterministic rule, and that rule then executes in milliseconds for everyone. A new attack becomes a rule in about an hour, and every installation gets the check without waiting for a signature vendor.

ATR is the standard; PanGuard is the free, MIT-licensed tool that is built on it and operates it. The relationship is like Sigma or CVE to the vendor that runs it. Before you install a skill or MCP server, you run pga scan <target> and it inspects the tool's declared and observable behavior against the rule corpus. Guard then does the same thing at runtime, so a version bump that adds a hidden BCC after install still gets caught when it acts.

The corpus is real and measurable. ATR ships nearly 690 rules (as of July 2026, npm agent-threat-rules v3.5.6) across 10 categories, with 866 rule-to-category mappings covering all ten OWASP Agentic Top 10 categories. On its Layer 1 deterministic rules, the SKILL.md corpus of 498 real-world samples measures 100% recall and 97% precision at a 0.2% false-positive rate. These are Layer 1 numbers on that specific corpus, not a single blended engine-wide figure, and the false-positive behavior is lane-based: roughly 0.24% in the enforce lane and about 9% in the default hunt lane against a 65,000-sample benign gate. State it plainly rather than quoting one precision number.

What should you do before installing your next MCP server?

Assume every MCP server is a supply-chain dependency that can change under you, because postmark-mcp proves it can. Pin versions, but do not treat pinning as protection, since the reason you upgrade is to get fixes. Scan behavior before install and monitor it at runtime, because the clean-then-poisoned bump is invisible to file-hash tooling by design. The install line is npm install -g @panguard-ai/panguard && pga up, and then pga scan <target> before you trust a new server with your email-sending credentials.

FAQ

Was postmark-mcp malicious from the start?

No. It shipped clean for most of its published life, then a version bump added the hidden BCC. That clean history is exactly why the poisoned version inherited trust and evaded reputation-based scanners.

Why couldn't antivirus catch it?

Antivirus matches artifacts against known-bad signatures, and a freshly poisoned version with a clean lineage matches nothing. Its good reputation from earlier honest releases actively worked in the attacker's favor.

Which OWASP Agentic Top 10 categories does this map to?

ASI04 Agentic Supply Chain Vulnerabilities (a trusted dependency turned hostile in an update) and ASI03 Identity and Privilege Abuse (the server abused email-sending authority it was legitimately granted).

How fast does ATR turn a new attack into a check?

About an hour. An AI understands the attack once, it is crystallized into a deterministic rule, and that rule then runs in milliseconds for every installation.

Run pga scan <target> on the next MCP server or skill you are about to install, before it gets your credentials. The ATR standard is open and MIT-licensed if you want to read the rules that back the check.