Clean for 15 Versions. Version 1.0.16 Stole Your Inbox.
An email-delivery MCP server published 15 clean versions. One point release added a single BCC line that forwarded thousands of emails per day to an attacker-controlled inbox. Plus: a typosquatting cluster of npm packages stealing SSH keys. Examples anonymized; no packages named.
> Note: The packages below are described by category, not by name. We do not name a real third-party package as malicious without a reproducible public CVE/advisory link.
The Attack
The skill was an MCP server that integrates with a transactional email API. It lets AI agents send and manage emails. For 15 versions it was clean. Standard email API wrapper. No suspicious behavior.
One later point release added one line of code: a BCC field on every outgoing email, forwarding a copy to an attacker-controlled inbox. If you were using this skill to send emails through your AI agent, every email -- business correspondence, customer data, internal communications -- was being silently forwarded.
Scale of Impact
Transactional email integrations typically send automated notifications, password resets, invoices, and business communications. A single busy integration can handle thousands of emails per day. Every one of those emails was duplicated to the attacker. The BCC field is invisible to the recipient -- the sender sees no indication that their email was forwarded.
Why Existing Tools Missed It
npm audit checks dependency vulnerabilities. It does not inspect application logic for behavioral changes between versions. GitHub Dependabot watches for known CVEs. A novel BCC injection has no CVE. Code review would catch it -- if anyone reviews the diff of every MCP server update. In practice, MCP servers auto-update, and nobody reads the changelogs.
ATR rule ATR-SC-003 (supply chain behavioral change detection) would flag this: it detects new network-adjacent operations (email sending, HTTP requests, WebSocket connections) added between versions. The BCC insertion is a modification to an existing network operation that changes the recipient set -- exactly the pattern the rule is designed to catch.
A Typosquatting Cluster
While investigating the email-skill case, we observed a coordinated typosquatting campaign targeting the MCP ecosystem. We track it internally as SANDWORM_MODE (no relation to the APT group -- the name comes from internal tracking). Around 19 npm packages published within a 48-hour window, each a near-miss of a popular MCP package name (for example, single-character variations of widely used CLI and server package names).
Every package in the cluster followed the same pattern: minimal functionality (often just re-exporting the legitimate package), plus a postinstall script that harvested ~/.ssh/id_rsa, ~/.aws/credentials, and all environment variables, then POSTed them to a Cloudflare Workers endpoint. The exfiltration was Base64-encoded and sent as a "telemetry" payload to a domain that looked like a legitimate analytics service.
Timeline
The cluster packages were live on npm for between 6 and 43 hours before removal. Download counts ranged from low double digits to a few hundred per package. Total estimated installations across the cluster: a few thousand. Each installation potentially compromised SSH keys and cloud credentials. If you install MCP tooling by typing package names by hand, double-check the spelling, and rotate SSH keys and cloud credentials if you suspect a typosquat install.
Lessons
Supply chain attacks on MCP are not theoretical. They are happening now. The attack model is identical to publicly documented npm incidents from 2018-2021 (event-stream, ua-parser-js, colors/faker), but the impact is amplified because MCP skills run with broader system access. Defense requires three things: (1) pre-install scanning that checks tool behavior, not just dependency versions, (2) version diff analysis that flags behavioral changes between releases, and (3) typosquatting detection against a known-good package registry. ATR and PanGuard provide all three.