Use case sources
Source reports and analysis supporting this case are listed below. AITBM interpretation and any indicative scoring are derived from this public evidence.
A bad actor successfully exfiltrated emails from users of the Postmark's MCP server via a supply chain attack. Postmark is an email delivery service that allows organizations to send marketing and transactional emails via API. The Postmark MCP server allows users to interact with Postmark via AI agents.
The bad actor impersonated Postmark, by registering the `postmark-mcp` package name on npm. They initially published the legitimate versions of the MCP server. After the package became popular and reached over 1,000 downloads per week, the bad actor performed a rugpull and uploaded a malicious version of the package. The malicious version added the bad actor's email address in the BCC line of all emails sent by the MCP tool. Users who upgraded to this version and continued to use the tool would have all emails exfiltrated to the bad actor.
ASSESSED SYSTEM
Representative configuration: an organisation's AI agent configured with the npm package postmark-mcp — a Postmark email MCP server published under a name Postmark had not registered — that upgraded to the malicious version 1.0.16 and used the server's email-sending tool to send transactional or promotional email through the organisation's Postmark account (MITRE ATLAS AML.CS0053, incident September 2025, reported by Koi Research). No victim organisation is named, so the assessment is of this configuration class: an MCP client that installs and upgrades third-party MCP server packages from a public registry and invokes their tools with the organisation's service credentials.
OUT OF SCOPE
The bad actor's npm account, the malicious package versions and the receiving mailbox (attacker tooling); Postmark's own email-delivery service and API, which were not compromised; the npm registry as a product; the model's handling of prompts, which the poisoned code did not use (the BCC was added in server code, not through model-visible content); and the Fairness axis (Fa-1..4).
Architecture: Agentic / MCP System (decision tree Q2) — Q1 = NO: no multi-agent topology is described. Q2 = YES: organisations configured the MCP server with their AI agents, users instructed the agents to use its tools, and the agents invoked the email-sending tool to perform an external action — sending email — on the organisation's behalf. Tier 2: Tier 2 Consumer: the exfiltrated material is the organisation's outbound email, including transactional email that the record says reveals private information about the organisation's clients, so harm reaches external individuals rather than staying inside one organisation's boundary.
Documented attack or failure path
- Postmark had not registered postmark-mcp on npm; the bad actor registered the name and published legitimate versions of a Postmark MCP server.
- After the package passed 1,000 downloads per week, the actor published version 1.0.16, which adds the actor's address to the BCC line of every email the tool sends — a rug pull that, per the record, evaded the additional scrutiny and scanning applied to new tools.
- Organisations that upgraded received the malicious version through the ordinary update path, and once configured with their agents its effects persisted.
- When users instructed their agents to use the server's tools, the malicious code executed, and the full contents of every email sent through the tool were copied to the actor.
- The exfiltrated email included transactional messages revealing client information and promotional messages revealing client lists.
Observed controls and bounded outcomes
Positive credit is given only where the record directly demonstrates a control operating. Recommended or merely presumed controls receive no positive scoring credit.
- Screening of newly published tools existed: the record states that by first publishing legitimate versions the actor 'was able to evade the additional scrutiny and scanning performed on new tools'. It did not extend to later versions, which is why Ro-4 is placed at 0.25 rather than 0.00.
Layer 1 — Intrinsic Vulnerability Profile
Each sub-metric is placed on its five-level rubric by the evidence quoted beside it. Missing applicable evidence remains unknown. The displayed midpoint and interval are scenario values, not inferred control performance.
| Sub-metric | Score | Rubric basis | Evidence |
|---|---|---|---|
| Robustness (Ro) — scenario interval 0.06–0.81 (midpoint 0.44), Tier 2 MVT 0.50 indeterminate | |||
| Ro-5Supply-Chain Artifact Admission Integrity | 0.25w 0.25 | 0.25 anchor: an admission control existed for the MCP-server artifact class — additional scrutiny and scanning applied to newly published tools — but there was no publisher-signature or provenance verification binding the package to Postmark, and the update path admitted version 1.0.16 by registry name alone. Not 0.00, because screening of new tools is evidenced; not 0.50, because no signature or hash verification covered the MCP-server class on either first install or upgrade. Moved from Ro-4 under the 26-sub-metric basis: the evidence concerns the admission of an unverified executable or loadable artifact, not content poisoning of data, retrieval, memory, tool descriptions or feedback, so Ro-4 is UNKNOWN. | The malicious BCC logic arrived as an update (version 1.0.16) to an already-adopted package; the record states that waiting for adoption let the actor 'evade the additional scrutiny and scanning performed on new tools', and organisations that upgraded accepted the poisoned version into their agents' tool set.source: secureflow/atlas |
| Fairness (Fa) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.55 indeterminate | |||
| Transparency (Tr) — scenario interval 0.05–0.85 (midpoint 0.45), Tier 2 MVT 0.50 indeterminate | |||
| Tr-4Model Lineage Disclosure | 0.25w 0.20 | The 0.25 anchor: limited lineage artifacts (registry name, version string) exist, but tool lineage — verified publisher, change history linked to review, provenance of each release — is incomplete. Not 0.00, because the registry origin and version 1.0.16 are identifiable; not 0.50, because the component's most material lineage fact, its publisher, was wrong. | Consuming organisations ran a package presented as Postmark's MCP server whose publisher was not Postmark — 'Postmark had not registered the postmark-mcp name on npm themselves' — and upgraded across versions without the behaviour change being visible to them; a registry name and a version number were the lineage they had.source: secureflow/atlas |
| Privacy (Pr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 2 MVT 0.55 indeterminate | |||
| Containment (Cn) — scenario interval 0.05–0.86 (midpoint 0.45), Tier 2 MVT 0.55 indeterminate | |||
| Cn-1Scope Enforcement | 0.25w 0.09 | The 0.25 anchor: a basic boundary exists — the tool is confined to sending email through the organisation's Postmark account — but a single added parameter (BCC) exceeded intended scope. Not 0.00, because the tool's reach stayed within its sending function; not 0.50, because the common violation (data sent to an unrequested external recipient) was not blocked. | The tool sent the organisation's email with an extra BCC recipient chosen by the package author, so every message sent through it also left for an unrequested external party; the exfiltration succeeded for every upgraded deployment that kept using the tool.source: secureflow/atlas |
| Cn-5Agent Identity Integrity | 0.25w 0.10 | The 0.25 anchor applied to the tool supply chain: registry-account identity with no cryptographic binding of publisher to vendor, so brand impersonation succeeded. Not 0.00, because the package was attributable to a registry account and a version; not 0.50, because no scoped or verified publisher identity is evidenced. Consistent with Cn-5 in clawhub-google-qx4-fake-prerequisite-malware. | The bad actor impersonated Postmark by registering the unclaimed postmark-mcp name, and 'legitimate users were tricked into using the npm package even though it wasn't managed by the official developers'; tool identity rested on a registry name with no binding to the vendor it claimed to represent.source: secureflow/atlas |
Unknown, not N/A: 22 applicable sub-metrics lack admissible public evidence. The lower, midpoint, and upper scenarios evaluate each at 0.00, 0.50, and 1.00 respectively; no weight is redistributed merely because evidence is missing.
Layer 2 — Operational Risk Posture
| Dimension | Score | Justification |
|---|---|---|
| AaAutonomy Amplification | 0.50w 0.25 | Placed at the 0.50 anchor. The agent invoked the email tool when users instructed it to, performing an external, irreversible action (sending email) on the organisation's behalf; the record evidences user-initiated tool use rather than self-directed or scheduled execution and is silent on per-message approval. The exfiltration ran inside server code and did not depend on agent judgment, so no higher autonomy is evidenced by this case. |
| AsAttack Surface Exposure | 0.75w 0.35 | Placed at the 0.75 anchor, consistent with deadbugz-mcp-supply-chain-campaign: the untrusted party is any publisher able to claim an unregistered name on a public package registry, reached through a deliberate install-and-upgrade step rather than through arbitrary runtime input; the email content itself is organisation-authored. |
| CpCascade Potential | 1.00w 0.20 | No System Dependency Graph with DGC at least 0.90 is published for this boundary, so the specification's worst-case graph default governs. The record also corroborates an ungated path from a public-registry publisher, through the organisation's MCP client and email tool (L3) holding its Postmark sending authority, to every outbound message and the client data it carries (L4) — a confidentiality terminal reached with no gate on the update path.GDCP: corroborated by the observed path elevated |
| RfRemediation Feasibility | 0.25w 0.20 | Deterministic remediation for the assessed deployment: remove or pin away from postmark-mcp 1.0.16, use a vendor-published server, rotate the Postmark credentials the package held, and review mail sent while it was installed. Held above 0.00 because the defect class — unclaimed names and post-adoption rug pulls on a public registry — recurs and needs standing supply-chain controls (version pinning, publisher verification, update review) rather than a single fix. |
Nelevated = 1 (dimensions strictly above 0.75) → CRM = 1.00.
Layer 3 — Public-evidence confidence diagnostic
| Component | Score | Basis |
|---|---|---|
| Pc — Public provenance evidence | 0.25 | The 0.25 minimal-provenance anchor. The package name, the malicious version (1.0.16), the injected BCC behaviour and the reporter are documented; no consuming deployment's client, model, credential scope or upgrade record is. |
| Ec — Public evaluation coverage | 0.13 | coverage 0.15 (4 of 26 applicable sub-metrics) × independence 1.00 × fidelity 0.85. No Full, Standard, or Lite pathway is claimed for a retrospective article. |
| Tf — Public-evidence freshness | 0.00 | Evidence dated 2025-09-01; age 412 days on the workpaper reference date. Components: T_containment 0.00 · T_calendar 0.04 · C_event 0.35 · C_evidence 0.85. Binding term: T_containment. dt_days = 412, measured from 2025-09-01 — the MITRE ATLAS AML.CS0053 incident date, recorded at month granularity (September 2025) and taken as the first day of that month — to the 2026-10-18 evidence reference date; the AIDEFEND SecureFlow conversion is dated 2026-08-06. agentic = true: the agent's tool set and the code behind it change with every package upgrade, so the containment staleness floor (M_Cn = 2.0) applies. baw = false: the poison is in server code that runs outside the model's context; the record evidences no change to the agent's prompts, memory, tool descriptions or other behavioural state, so no Behavioral Attestation Window checklist item is met. C_event = 0.35: a malicious tool version executed in production deployments — a major tool-authority compromise event. C_evidence = 0.85: an unknown population of deployments that installed 1.0.16, with no recorded closure. |
Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.04 — diagnostic status: Invalid as assessment-of-record evidence. It describes the evidence available to this case study, not the assurance of the underlying system, and is not inserted into the normalized-assurance scenario ERS.
Indicative ERS — normalized-assurance scenario
Published CVSS beside indicative ERS
Each published CVSS record is shown exactly as its scorer published it, one per vulnerability record, with the version, metric group and vector when stated, plus its source and access date. Records are never combined or inferred from a CVE's existence.
INDICATIVE ERS · NORMALIZED-ASSURANCE SCENARIO
3.8 midpoint, interval 1.4–6.2; Low-Moderate scenario band; ACI fixed at 1.00. The published CVSS records do not enter this calculation.
PUBLISHED CVSS
CVSS — no applicable published score verified.
CVSS describes an individual vulnerability as its scorer published it. Indicative ERS describes the assessed AI deployment under the normalized-assurance scenario, so the two values are not direct equivalents and neither replaces the other.
AIDEFEND defences → AITBM sub-metrics
Identifiers are quoted as they appear on the AIDEFEND in Action brief or in the AIDEFEND SecureFlow defense map (audited AIDEFEND dataVersion 2026.10.15); the sub-metric mapping is AITBM's own, from the specification's AIDEFEND tables reconciled at catalogue data version 2026.10.15. AIDEFEND renumbers identifiers between releases, so the data version travels with every mapping and neither side's IDs should be cited without one. A mapping identifies a possible evidence route; a recommendation does not prove that the control was implemented or effective and receives no scoring credit by itself.
| Technique | Defence | Priority | Evidences |
|---|---|---|---|
| AID-H-024.001 | Fully Qualified Tool ID & Version PinningExact SecureFlow defense-map identifier (flow atlas-aml-cs0053-poisoned-postmark-mcp-server-email-exfiltration), verified against AIDEFEND dataVersion 2026.10.15; matched to attack steps step-4, step-5. Presence supplies no score credit. | Candidate evidence route | Cn-5 |
| AID-H-024.004 | Approved Tool Contract Semantics & Change AdmissionExact SecureFlow defense-map identifier (flow atlas-aml-cs0053-poisoned-postmark-mcp-server-email-exfiltration), verified against AIDEFEND dataVersion 2026.10.15; matched to attack steps step-4, step-5. Presence supplies no score credit. | Candidate evidence route | Cn-5 |
| AID-H-003.001 | Software Dependency & Package SecurityExact SecureFlow defense-map identifier (flow atlas-aml-cs0053-poisoned-postmark-mcp-server-email-exfiltration), verified against AIDEFEND dataVersion 2026.10.15; matched to attack steps step-4, step-5. Presence supplies no score credit. | Candidate evidence route | Ro-4 Ro-5 Tr-4 |
| AID-H-023 | Publisher Integrity & Workflow HardeningExact SecureFlow defense-map identifier (flow atlas-aml-cs0053-poisoned-postmark-mcp-server-email-exfiltration), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-5. Presence supplies no score credit. | Candidate evidence route | Ro-5 Tr-4 |
| AID-H-021.002 | Runtime Integrity Enforcement (Signed Configurations)Exact SecureFlow defense-map identifier (flow atlas-aml-cs0053-poisoned-postmark-mcp-server-email-exfiltration), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-6. Presence supplies no score credit. | Candidate evidence route | Cn-2 Cn-5 Cn-9 |
| AID-D-004.003 | Runtime Configuration & Policy Drift Detection and MonitoringExact SecureFlow defense-map identifier (flow atlas-aml-cs0053-poisoned-postmark-mcp-server-email-exfiltration), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-6. Presence supplies no score credit. | Candidate evidence route | Ro-5 Tr-3 Cn-7 Cn-9 |
| AID-H-018.005 | Value-Level Capability Metadata & Data Flow Sink EnforcementExact SecureFlow defense-map identifier (flow atlas-aml-cs0053-poisoned-postmark-mcp-server-email-exfiltration), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-8. Presence supplies no score credit. | Candidate evidence route | Cn-1 Cn-6 Cn-7 |
| AID-H-018.002 | Policy-Based Access ControlExact SecureFlow defense-map identifier (flow atlas-aml-cs0053-poisoned-postmark-mcp-server-email-exfiltration), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-8. Presence supplies no score credit. | Candidate evidence route | Cn-1 Cn-6 Cn-7 |
| AID-D-003.003 | Agentic Tool Use & Action Policy MonitoringExact SecureFlow defense-map identifier (flow atlas-aml-cs0053-poisoned-postmark-mcp-server-email-exfiltration), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-8. Presence supplies no score credit. | Candidate evidence route | Ro-3 Cn-1 Cn-3 Cn-7 |
| AID-D-003.002 | Sensitive Information & Data Leakage DetectionExact SecureFlow defense-map identifier (flow atlas-aml-cs0053-poisoned-postmark-mcp-server-email-exfiltration), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-8. Presence supplies no score credit. | Candidate evidence route | Ro-3 Cn-1 Cn-3 Cn-7 |
| AID-E-003.003 | Confirmed Malicious Code & Persistence EvictionExact SecureFlow defense-map identifier (flow atlas-aml-cs0053-poisoned-postmark-mcp-server-email-exfiltration), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-9. Presence supplies no score credit. | Candidate evidence route | Ro-4 |
| AID-E-001.001 | Root & Long-Lived Credential Object EvictionExact SecureFlow defense-map identifier (flow atlas-aml-cs0053-poisoned-postmark-mcp-server-email-exfiltration), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-9. Presence supplies no score credit. | Candidate evidence route | Cn-5 |
| AID-R-004 | Fleet Remediation Propagation & Technical Recurrence PreventionExact SecureFlow defense-map identifier (flow atlas-aml-cs0053-poisoned-postmark-mcp-server-email-exfiltration), verified against AIDEFEND dataVersion 2026.10.15; matched to attack step step-9. Presence supplies no score credit. | Candidate evidence route | ORP:Rf remediation evidence |
WHAT THIS CASE TEACHES
A tool supply-chain compromise can bypass the model entirely: the BCC was added in server code, so no prompt-injection or output control could have seen it, and AITBM places the evidence on Ro-5, Tr-4, Cn-1 and Cn-5 — the integrity, lineage, scope and publisher identity of the tool — while leaving Ro-1 unknown rather than inferring a model failure.
Sources: AIDEFEND SecureFlow — Poisoned Postmark MCP Server Email Exfiltration · MITRE ATLAS case study AML.CS0053 · First Malicious MCP in the Wild: The Postmark Backdoor That's Stealing Your Emails (koi.ai)
SecureFlow attack flow
This record mirrors an AIDEFEND SecureFlow flow (MITRE ATLAS case-study conversion): an ordered attack path with MITRE ATLAS tactic and technique labels and the AIDEFEND controls matched to each step. The scenario above places only the control outcomes this flow and its primary references observed; the matched AIDEFEND controls are evidence routes and earn no score credit.
| MITRE ATLAS case study | AML.CS0053 (incident) |
|---|---|
| Target | Postmark MCP Server |
| Actor | Unknown Bad Actor |
| Reporter | Koi Research |
| Primary evidence date | 2025-09-01 |
| SecureFlow record updated | 2026-08-06 |
| AI layers | Autonomous agents, Tool integrations / MCP, AI supply chain |
| Risk impact | Data exfiltration |
| Affected components | Postmark MCP server npm package, AI agent MCP client, email sending tool, npm package update path, outbound email recipient and BCC fields |
Attack steps
| # | Step | ATLAS tactic / technique |
|---|---|---|
| 1 | Impersonate Postmark PackageThe bad actor impersonated Postmark by publishing a legitimate version of their `postmark-mcp` package to npm. Postmark had not registered the `postmark-mcp` name on npm themselves, allowing the bad actor to namesquat. Legitimate users were tricked into using the npm package even though it wasn't managed by the official developers of `postmark-mcp` | AML.TA0007 AML.T0073 |
| 2 | Backdoor Email Tool with BCCThe bad actor modified the legitimate Postmark MCP server to include their email address on the BCC line on all emails sent by the tool. | AML.TA0003 AML.T0017 |
| 3 | Publish Poisoned MCP PackageThe bad actor published their malicious version of `postmark-mcp` to npm. | AML.TA0003 AML.T0115.002 |
| 4 | Rug Pull Trusted Package VersionBy waiting for users to adopt a legitimate version of `postmark-mcp` first, the bad actor was able to evade the additional scrutiny and scanning performed on new tools. | AML.TA0007 AML.T0109 |
| 5 | Upgrade to Poisoned MCP ServerWhen organizations upgraded `postmark-mcp` to version `1.0.16`, they received the malicious version of the tool via the compromised supply chain. | AML.TA0004 AML.T0010.005 |
| 6 | Persist as Configured Agent ToolOnce configured with the organization's AI agents, the poisoned Postmark MCP server's effects persist. | AML.TA0006 AML.T0110.001 |
| 7 | Execute Poisoned Email ToolWhen users at the victim organization instructed their AI agent to use tools provided by the poisoned Postmark MCP Server, the malicious code was executed. | AML.TA0005 AML.T0011.002 |
| 8 | Exfiltrate Emails via Hidden BCCWhen organizations sent emails via the `postmark-mcp` tool, the entire contents of their emails are exfiltrated to the bad actor via the address added on the BCC line. | AML.TA0010 AML.T0086 |
| 9 | Cause Client and User Data HarmThe exfiltrated emails may include transactional emails (revealing private information about the organization's clients) and promotional emails (revealing the organization's client list). | AML.TA0011 AML.T0048 |
Threat references
Summary and attack steps reproduced from AIDEFEND SecureFlow (https://aidefendlabs.com/en/secureflow/?flow=atlas-aml-cs0053-poisoned-postmark-mcp-server-email-exfiltration; AIDEFEND content CC BY 4.0), converted from MITRE ATLAS case study AML.CS0053 (Apache License 2.0; MITRE ATLAS is a trademark of The MITRE Corporation).