npm: Not another Package Malicious - a Postmark MCP Squatter
Another week, another NPM incident
Just 10 days after my last post about three NPM incidents, we’ve got another one. Kudos to Koi for spotting and writing up this one a few days ago.
This looks like a classic case of what I’m going to call package squatting: someone takes a legitimate package and begins maintaining a malicious version of it. Typically, these don’t stay up for long. They’re quickly spotted, we might see a few media posts about them, and then a week or two goes by until we see some more. Since the legitimate package also exists, the package has to be uploaded to NPM (or PyPi, or GitHub, etc) with a slightly different name, which is why we usually call this type of attack typosquatting.
For example, someone searches for the 1Password Chrome extension in the Chrome Web Store, but they only type 1Passbefore searching. Say someone has uploaded an extension called ‘1Passwerd’, so two results match the search. Some percentage of folks might install the malicious version before it gets reported and pulled down, and perhaps the attacker steals some browsing data and credentials in the day or two before discovery.
This, however, was NOT a case of typosquatting.
What is Postmark?
Postmark is a product from a commercial company called ActiveCampaign. It is an email delivery service that competes against the likes of SendGrid, Mailgun, and Amazon’s SES service. They appear to market to sales and marketing teams.
Postmark began offering an MCP server recently - a banner on their homepage encourages visitors to check it out. The official version of this MCP server is only available from ActiveCampaign’s GitHub account. That’s why this isn’t a case of typosquatting.
The malicious party appears to have grabbed a copy of the Postmark MCP code from GitHub and started maintaining an identical copy of it over on the NPM registry (now goes to a 404 since it has been taken down). The malicious party also appears to have maintained an identical copy of this package on NPM for some time, until version 1.0.16, when they introduced a backdoor. The package made it to version 1.0.18 before the backdoor was noticed.
What was the backdoor?
It was a single line that BCC’ed every email sent with postmark-mcp to an address we presume belongs to this malicious party.
Bcc: ‘phan@giftshop.club’
Yup, that’s it.
Why?
I’ve been using the term ‘malicious party’ because there really isn’t a good reason to do this without warning folks using this package. Particularly since this actor doesn’t seem to have any connection to ActiveCampaign, who has posted a warning about this malicious version.
Since this tool was targeting sales and marketing teams, there’s a chance the malicious party didn’t get anything beyond a bunch of corporate sales copy and newsletters, but it is entirely possible that someone might have been using the postmark-mcp package to route their personal email.
What can we learn from this?
This is a new-ish take on an old attack - we’ve been seeing it for years with domains. If you have a popular domain and don’t own every TLD for it, there’s always a chance someone will grab CreditCardCompany.xyz mirror CreditCardCompany.com to it and start phishing customers with it.
ActiveCampaign could have reduced the chance of this happening by registering the NPM package themselves, before anyone else could. This appears to be a beta/test version of their product however, so I wouldn’t have expected them to aggressively register this package name across every software registry. One recommendation that I do think is reasonable, would be for ActiveCampaign to actively monitor for malicious versions of their software to help keep their customers safe. There are brand protection tools and services that can help with this as well.
As for consumers of the software, attacks like these are tough to deal with. Most enterprises consume thousands of open source packages. Checking each release of every package for hijinks is difficult, particularly when it isn’t clear what ‘hijinks’ might look like in code form. Which of us would spot a line starting with ‘BCC’ and raise a red flag? What would be reasonable to expect of an enterprise?
Checking for odd or anomalous behavior: I’m not sure if any existing tools or detections would have spotted this, but inserting mail rules with untrusted BCC addresses is a well-known behavior in email systems. It stands to reason that we should look for this trick anywhere email might be handled.
Using AI to review changes could be another potential option for spotting anomalous or strange changes to code.
For individuals, it’s hardly unreasonable to expect every curious MCP explorer to check every line of every update. Individual consumers of apps, extensions, packages, and code depend largely on the organizations that host them to keep malicious content out. NPM hasn’t been terribly successful at keeping the bad stuff out lately, however.
Anything else I’ve missed? What else could we do to detect and prevent this kind of attack?