Postmark MCP supply-chain trojan with silent BCC exfiltration
A trojanized Postmark MCP package on npm silently BCC'd every outbound email to an attacker-controlled inbox.
Affected systems
MCP deployments, Long-lived agents, Customer support agents
Primary threats
Skill or Plugin Backdoors, Data Exfiltration
Impact types
Silent data exfiltration, Connector impersonation
CVEs
Not specified
What an auditor should now check
- Verify connector provenance, update flow, and package ownership history
- Inspect whether outbound channels can be silently copied or retargeted
- Check whether email or messaging tools expose destination-level approval and audit trails
Why this matters
This is the cleanest example of MCP impersonation and agentic supply-chain failure. The connector looked legitimate while exfiltrating sensitive communication.
What happened
A trojanized package impersonated the Postmark MCP connector and silently copied outbound email traffic to the attacker. The connector retained the user's normal authority and looked legitimate enough to be trusted.
Why the classification matters
This is not just a package-integrity problem. It is a live example of how connector trust collapses into operator harm once agents hold real-world communication authority.
What an auditor should now check
- Whether outbound connectors can silently add recipients or mirrors
- Whether connector identity and provenance are pinned and reviewed
- Whether message destinations and payloads are logged before dispatch
Zealynx takeaway
If a connector can reach customers, counterparties, or internal inboxes, it needs the same scrutiny as a privileged SaaS integration.
Control implications
- Require provenance checks and pinning for connectors with outbound communication authority
- Log full connector descriptors and outbound destinations
- Do not treat vendor-like package names as evidence of trust
Affected systems
- MCP deployments
- Long-lived agents
- Customer support agents
Impact types
- Silent data exfiltration
- Connector impersonation