A Postmark backdoor that’s downloading emails

https://www.koi.security/blog/postmark-mcp-npm-malicious-backdoor-email-theft

by ghuntley • 10 months ago

308 163 10 months ago

koi.security

hdjdndndba• 10 months ago

Bait article with an awful chatgpt generated image at the top to boot.

nativeit• 10 months ago

How is it “bait”? It’s covering a fairly brazen supply chain attack, what were you expecting?

bonsai_spool• 10 months ago

Perhaps not something displaying every hallmark of an AI-generated article.

akagusu2• 10 months ago

The new Outlook app keeps a copy of all your e-mails, including your e-mail credentials, at Microsoft servers. Microsoft is doing this for months to millions of people and nobody cares. Why a single developer copying a couple hundreds of e-mails is such a big deal?

two_handfuls• 10 months ago

Two wrongs do not make a right

fathermarz3• 10 months ago

Microsoft Servers != Malicious Actors Computer

aleph_minus_one2• 10 months ago

Microsoft Servers != Malicious Actors Computer

Whether this statement does hold or not depends a lot on your personal worldview:

- How do you define "malicious"?

- Is Microsoft a malicious [in the sense of your previous answer] actor (or not)?

- What is the result of your risk assessment that Microsoft will become a malicious in the future?

anonym29• 10 months ago

You choosing not to care about Microsoft's extensive and well-documented history of adversarially abusing, misleading, lying to, spying on, harassing, and stripping control away from their own end users doesn't mean Microsoft isn't malicious.

Microsoft sees and treats their end users simultaneously as adversaries, as incompetent children, and as data cows to be milked without genuine informed consent for Microsoft's own profit, not as customers deserving of respect, dignity, and autonomy.

akagusu2• 10 months ago

Microsoft Servers === Malicious Actors Computer because both are doing exactly the same thing, copying your e-mails to their servers.

AznHisoka• 10 months ago

Good thing i dont even wanna use any 3rd party libraries when using stuff like Postmark. Just old fashioned curl and POST requests to send emails with Postmark.

And i consider myself a lazy person. Using 3rd party libraries are just more of a headache and time sink sometimes

bfelbo• 10 months ago

Yeah, this was the case before MCPs as well. Especially with some of the really bloated SDKs (looking at you Firebase and Twilio).

thepill• 10 months ago

I understand the problem mentioned with mcp servers but this kind of attack could happen to any external dependency (like a smtp package) i guess

WD-42• 10 months ago

The difference is if you went looking for a smtp package you’d land on an established library with a track record and probably years worth of trust behind it. The Mcp stuff is so new all of that is missing, people are just using stuff that appeared yesterday. It’s the Wild West, you need to have your six shooter ready.

hn87262• 10 months ago

The "postmark-mcp" from the article seems like some random guy's package though, postmark has its own official mcp server as well: https://postmarkapp.com/lp/mcp. It's like installing ublock extension but published by a 'coder3012' account

jinwoo68• 10 months ago

It's almost always npm packages. I know that's because npm is the most widely used package system and most motivating one for attackers. But still bad taste in my mouth.

hendersoon• 10 months ago

This is why I don't run stdio MCP servers. All MCPs run on docker containers on a separate VM host on an untrusted VLAN and I connect to them via SSE.

Still vulnerable to prompt injection of course, but I don't connect LMs to my main browser profile, email, or cloud accounts either. Nothing sensitive.

greatgib• 10 months ago

If you used this package, you would still have been victim of this despite your setup. All your password reset or anything sent by your app BCC to the bad guy.

iagooar2• 10 months ago

Even OpenAI uses npm to distribute their Codex CLI tool, which is built in Rust. Which is absurd to me, but I guess the alternatives are less convenient.

tonyhart72• 10 months ago

nah bro you got it wrong

its the other way around, codex started with TS then rewrite it to rust

xpe6• 10 months ago

Here is hoping the above comment isn't upvoted to the point where it is portrayed as something like a "key takeaway" from the article. That would be missing the point.

dpflan2• 10 months ago

Or send a prompt injected spam in someone's GMail, doesn't even have to opened by the human end-user:

https://www.linkedin.com/posts/eito-miyamura-157305121_we-go...

xpe6• 10 months ago

Somehow, we've all just accepted that it's totally normal to install tools from random strangers that can

Some people do this without thinking much about it. Not all of us. This is not normal nor ok.

Predicting this kind of attack was easy. Many of us probably did. (I did.) This doesn't make me feel much better though, since (a) I don't relish when lazy or ignorant people get pwned; (b) there are downstream effects on uninvolved people; and (c) there are classes of attacks that are not obvious to you or me.

Stay suspicious, stay safe. There are sharks in the water. With frikin' laser beams on their heads too.

ako• 10 months ago

I'm running linux, millions of lines of code i never verified, and may or may not have been verified by trustworthy people. In the end it's one big risk. When i'm developing in go, it's pulling in many lines of code i don´t have time for to validate, same with java, so many jars. Who knows what i'm running...

SoftTalker3• 10 months ago

And every distro has a different mix of packages that they install by default. There's no "standard" linux installation.

xpe6• 10 months ago

I don’t know where to start with the comment above. First, different code bases receive different levels of scrutiny, so factor this in. Second, there are tools that can help with supply chain security. Third, security isn’t all or nothing; we can and do make decisions under uncertainty. Fourth, who is accountable when things go badly?

mattxxx• 10 months ago

It's pretty daring to do something like this. Something so brazen has a 100% chance of getting caught given enough time...

That said, installing any package is a liability, whether it's a library or an mcp server.

xpe6• 10 months ago

Perhaps. Or perhaps not. What are the likely consequences when this happens? Plausible deniability might work here -- and it might even be true.

Dilettante_2• 10 months ago

Well, here's the thing not enough people talk about: we're giving these tools god-mode permissions. Tools built by people we've never met. People we have zero way to vet. And our AI assistants? We just... trust them. Completely.

I keep seeing this pattern in articles: "Did you know that if you point the gun at your foot and pull the trigger, yOu ShOoT yOuRsElF iN tHe FoOt??!? I couldn't believe it myself!! What a discovery!!1!"

Are people really this oblivious or are these articles written about non-issues just to have written 'content'?

BobbyTables2• 10 months ago

These also remind me on the early 1980s mentality of some who thought anything printed by a computer must be correct.

It’s an AI, it must be perfect! /s

avs733• 10 months ago

This is unfair. It presumes a universal understanding of something largely because it is obvious to us. Most computer users have little to know detailed understanding of how any computer technology works, and because they are invisible and abstract, even less understanding of the risks they expose themselves to.

The answer to you gun analogy is false because it assumes basic knowledge of a gun. This is part of why so many kids shoot themselves or family members with guns - because they don’t know if you pull the trigger something violent will happen until they are taught it.

Dilettante_2• 10 months ago

But these are not children, and they were not just handed a gun. They went out and acquired one.

That is what astounds me. How one can come into possession of a gun completely without understanding that it is dangerous. How fundamentally the worlds I and they live in must be for that to happen.

Oh, now that I write it out like that, I've definitely been on the other side of that astoundment before, for lacking 'common sense'. Ain't that just the way.

lazide• 10 months ago

Did you know that if you give a loaded gun to a chimpanzee, sometimes it will shoot you (or itself) and it didn’t even know that was going to happen?!? Even if you tell it several times?!?

And that if that happens ‘smart’ people will tell you that it was really dumb to do that!!?!

ljm2• 10 months ago

What’s obvious to the audience of HN isn’t necessarily obvious to anyone else.

Articles like this are intended to serve the latter group of people.

And it’s true, AI agents with MCP servers are pretty much unsafe by design, because security was never considered from the start. Until that changes, if it ever even does, the best thing to do is to inform.

didericis• 10 months ago

the best thing to do is to inform.

While also not using them yourself/actively trying to find and strip them out of workflows you have control over.

dawnerd• 10 months ago

The recent npm supply chain attacks were directly targeting people in the HN crowd. Don’t think because you’re here and know tech that you’re immune.

drdaeman4• 10 months ago

Until that changes

MCP is just JSON RPC API dialect. It is not "safe" or "unsafe" by design - it's a layer where notion of safety (as talked about in the article) is not applicable. Saying that "MCP is unsafe" is not a meaningful statement in the scope of what MCP is. Nothing about any RPC (by itself) can guarantee that the remote system would do or not do something when some method is invoked.

Unless someone figures out a way to make end-user comprehensible language for formal software verification, so there could be an accompanying spec that describes the behavior to the dot, and technology that validates the implementation against the spec.

Right now the only spec is the actual codebase, and most users aren't typically reviewing that at all.

askl2• 10 months ago

Do people outside the HN audience exist that are using MCP servers?

bsder• 10 months ago

What’s obvious to the audience of HN isn’t necessarily obvious to anyone else.

AI amplifies the problem.

Before AI, the idiot who accidentally has too much access probably doesn't have the ability to actively exploit it.

Given how much AI is being shoved down everybody's throats, an idiot with access now is an attack vector because they are have neither the ability nor desire to vet anything the AI is feeding to them.

kemayo• 10 months ago

There was that article a few months ago about an AI code assistant deleting a company's production database: https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-d...

There's layers here, of course:

1. The founder shot themselves in the foot by not understanding an AI tool couldn't be trusted, so clearly they really were that oblivious.

2. ...the founder had direct production access hooked up to their regular coding environment. They were always going to shoot themselves in the foot eventually.

askl2• 10 months ago

That's a really heartwarming story. Thanks.

Aurornis• 10 months ago

There was that article a few months ago about an AI code assistant deleting a company's production database

That wasn’t a company. It was a vibe coding experiment. It didn’t have any actual customers.

It did delete the database marked “production” though. If it had been deployed it would have been a problem. It was just an experiment, though.

m3047• 10 months ago

There was a time when email clients running scripts in emails from randos on the internet was "a game-changing opportunity for automation". Here we are again.

There was a time when people thought letting their children use the internet as a babysitter was healthier than parking them in front of the television... guess that turned out another way.

zobzu• 10 months ago

The problem, especially with AI, IMO is that folks are even more willing to shoot themselves in the foot.

IMO this might be due to a few things like these:

1. Folks are trained on buffer overflows and SQL injections, they don't even question it, these are "bad". But an MCP interface to an API with god-like access to all data? The MCP of course will make sure its safe for them! (of course, it does not). It's learning and social issue rather than a technical issue. Sometimes, it makes me feel like we're all LLMs.

2. 300 things to fix, 100 vendors, and it needs to be done yesterday. As soon as you look into the vendor implementation you find 10 issues, because just like you, they have 300 things to fix and it needs to be done yesterday, so trade-offs become more dangerous. And who's going to go after you if you do not look into it too hard? No one right now.

3. Complete lack of oversight (and sometimes understanding). If you're just playing around by prompting an LLM you do not know what its doing. When it works, you ship. We've all seen it by now. Personally, I think this one could be improved by having a visual scheduler of tasks.

collinmcnulty• 10 months ago

I think the issue is that the security issue is inherent to the core story being told about AI. “It can read your emails and respond automatically” is both a pretty compelling story to certain people who aren’t waist deep in tech news, and also exceedingly dangerous.

flowerthoughts• 10 months ago

https://xkcd.com/1053/

Today, 10,000 Americans discovered that water is wet for the first time. Same thing tomorrow.

scuff3d• 10 months ago

Surely giving an unpredictable AI access to your system has absolutely no downsides at all.

zahlman4• 10 months ago

Are people really this oblivious

Last I checked, basic SQL injection attacks were still causing massive economic damage every year and are at or near the top of the OWASP list. SQL injection is essentially the result of unintentionally giving god-mode permission to a database by failing to understand how queries are built and processed. The... agency available to AI agents might not be all that obvious either.

OptionX• 10 months ago

And we have decades of hindsight with sql injection to work with and make it obvious. No so much with all the fancy new AI tools.

Yes MCP has next to no security features, but then again is it even a year old at this point?

Not excusing it just pointing out something folks should me mindful of when using tool based on it, its an immature system.

And heck, I still remember a time when most of the internet traffic just flew around in plain text. Insanity to us now.

tomjen3• 10 months ago

I am going to disagree with that. SQL injection attacks are an example of the age old issue of mixing up input and instructions. Smash the stack is older than many software devs, but it was essentially the same problem - its an inherit issue with Von Neumann architecture.

This is also not an AI issue, or even an MCP issue. If the same issue had been in a client library for the Postmark API, it would likely have had a bigger impact.

What we need is to make it much more likely to get caught and go to prison for stuff like this. That will change things.

kordlessagain2• 10 months ago

Speak for yourself.

Terr_• 10 months ago

If you look at human civilization in general, it is full of cases where people need to be convinced that their bullet-wounded feet aren't "just the way it works", that fixing it is possible, and that the wounds are serious enough to be worth it.

ChuckMcM2• 10 months ago

Are people really this oblivious ...

Yes, yes they are. The vector of "I've been using this package and giving it full permissions for like forever and it has never been a problem." oblivious. One must understand the two-step here:

Step 1) Use someone else's package that solves your problem and doesn't have any issues. Yay you're doing DRY and saving time and effort!

Step 2) The package you got is now corrupted but you don't have any tools to checking to see if you're application is doing anything sus.

The alternative is that you audit every release and look at every change on every file. So suddenly your DRY because a weekly/monthly audit exercise for every single imported package that changes. Use three packages, that's three audit schedules. Use ten? That's ten audit schedules. It's stupid because if you actually used this alternative you'd be spending all of your time just auditing packages and 90+% of the time not finding anything to complain about.

So the ACTUAL alternative, is write your own damn code. You wrote it so you know how it works, and when you change it you know what you changed. And unless you are the bad guy, exploits don't "magically appear" in your code. Vulnerabilities will appear in your code if you don't do code reviews, but remember actualizing this stuff requires both knowing about the bug and exploiting it in the wild, you may end up coding in something that could be exploited but you are unlikely then to use your own vulnerability.

PantaloonFlames5• 10 months ago

Step 1 sounds like npm, to me.

and Step 2.... ? yeah, we know.

"Write your own code" won't scale. Anyway that horse is out of the barn. We need better SBOM tools.

cyanydeez• 10 months ago

Are people just aching to constantly blame poor people for moral and ethical failings, and not the grifters who prey on them?

Yes. People definitely blame victims all the time. There's no way LLMs, their proprietors, designers could be practicing dark patterns, marketing gimmicks and security shortcuts to convince people to shot these guns as often as possible...even when, they point them at their foot.

This grift is deep and wide and you may want to re-evaluate why everyone is so keen to always blame victims for technology, society, and business marketing.

jszymborski• 10 months ago

The problem with foot guns is that you know it's a foot gun and I know it's a foot gun, but the underpaid social media manager at my bank might not and suddenly it's a problem for you and I.

tokioyoyo• 10 months ago

It’s a bit easy for us to say, but general public doesn’t know about the details. For example, lots of people talk how algorithms designs your personal social media feed. But the same people don’t know what an “algorithm” means. It’s just a generic word for them. Which is fine, because not everyone is in our industry.

anal_reactor• 10 months ago

What security people don't understand is that if insurance policy costs more than "cost of disaster" times "probability of a disaster" then it's most likely not worth it. They personally enjoy doing security stuff, so they don't internalize the costs of maintaining a secure environment the same way an average person does, or even a non-security developer.

OJFord• 10 months ago

People are doing this with MCP on large scale, it's not talked about enough; otherwise sensible people are dismissive of the risks.

latexr4• 10 months ago

Are people really this oblivious

There are hundreds of accidental gun deaths every year in the US. So yes, people do need to be told to not point guns at their feet (and other body parts) and pull the trigger.

https://ammo.com/articles/accidental-shooting-statistics

Just the other day I saw a video of a guy pulling a trigger on a gun in another person’s hand with the express goal of inuring them with the knock back. Another of a guy accidentally shooting a hole through his own ceiling. And a third one of a guy (there were at least three people present) shooting a rifle into a shallow river; they were lucky the barrel exploded like a looney tunes cartoon.

And we’re talking guns, which are designed to be dangerous. Software is much more nebulous and people have been conditioned for years to just download whatever and install it.

afrisch2• 10 months ago

How is this different from a backdoor in, say, a Thunderbird extension? I've maintained an extension for Thunderbird and, when I was no longer interested in it, a guy pushed hard to take over the project after sending a few legitimate contributions. I declined because it seemed crazy to give the keys to tens of thousands mailbox to a guy I didn't really know. I also found it crazy that people would trust me initially, but well, I know I'm a good guy :-)

SoftTalker3• 10 months ago

Yeah I thought the same thing. This has nothing to do with MCP really, the same flaw is there in all software: you have to trust the author and the distributor. Nothing stops Microsoft from copying all your Outlook mail. Nothing stops Google from copying all your gmail. Nothing stops the Mutt project from copying all your email. Open source users like to think that "many eyes" keep the code clean and they probably do help, especially on popular projects where all commits get reviewed in detail, but the chance is still there. And the rest of us just trust the developers. This problem is as old as software.

phatskat• 10 months ago

This problem is as old as software.

Sure, I agree, and the problem is absolutely magnified by AI. If a back door gets into Thunderbird, or Google decides to start scanning and sharing all of your email, that’s one point of failure.

An MCP may connect to any number of systems that require a level of trust, and if any one thing abuses that trust it puts the entire system at risk. Now you’re potentially leaking email, server keys, recovery codes, private documents, personal photos, encrypted chats - whatever you give your AI access to becomes available to a single rogue actor.

PantaloonFlames5• 10 months ago

Nothing stops Microsoft.... Nothing stops Google...

Not really true. They have skin in the game. They have legitimate revenue at stake. If they betray trust on such a scale, and we find out, they'll be out of business.

thaumasiotes• 10 months ago

Open source users like to think that "many eyes" keep the code clean and they probably do help, especially on popular projects where all commits get reviewed in detail, but the chance is still there.

The https://en.wikipedia.org/wiki/XZ_Utils_backdoor bears mentioning here.

dpflan2• 10 months ago

I recall the noted Zuckerberg comments regarding the situation you describe of why people are willing to trust you with their privacy and data...

EasyMark• 10 months ago

I have helped many extremely drunk people this way, given them a lift, but point out to them that getting a lift from a stranger you just met is a really bad idea. they're just lucky they met an honest guy with some free time because I keep weird hours and like the neighborhood hole-in-the-wall pub.

latexr4• 10 months ago

getting a lift from a stranger you just met is a really bad idea.

Giving a lift to a drunk stranger you just met is also a bad idea. Not a criticism—what you’re doing is positive—but it’s also a risk for you.

latexr4• 10 months ago

How is this different from a backdoor in, say, a Thunderbird extension?

I don’t get the argument. Had this been a backdoor in a Thunderbird extension, would it not have been worth reporting? Of course it would. The value of this report is first and foremost that it found a backdoor. That it is on an MCP server is secondary, but it’s still relevant to mention it for being the first, so that people who don’t believe or don’t understand these systems can be compromised (those people exist) can update their mental model and be more vigilant.

everdrive• 10 months ago

For 15 versions - FIFTEEN - the tool worked flawlessly. Developers were recommending it to their teams. "Hey, check out this great MCP server for Postmark integration." It became part of developer’s daily workflows, as trusted as their morning coffee.
Then version 1.0.16 dropped. Buried on line 231, our risk engine found this gem: A simple line that steals thousands of emails
One single line. And boom - every email now has an unwanted passenger.

A brand new twist on enshittification.

ricardobeat2• 10 months ago

What stops police/a prosecutor from getting a warrant for Squarespace/GoDaddy to give them info on the purchase of the giftclub.shop domain? Their payment method is identifiable, I doubt someone commiting this kind of attack is covering their traces very well.

manquer• 10 months ago

Stolen credit cards are not very difficult to get hold for these kind of people I imagine so it won’t be so straightforward as just getting data from the provider.

However jurisdiction and lack of funding for cybercrime policing is the main reason criminals don’t get caught .

Many cybercriminals operate in countries that do not cooperate, extradite and may even have tacit state approval .

Only the largest police departments like NYPD and few federal agencies like FBI have some cybercrime investigations capability and very little of that is for investigating crimes against individuals rather than institutional victims.

It is not an unsound approach when resources are limited you would want to prioritize institutions as that would protect or serve more individuals indirectly .

However the result is that you are far more likely get policing support when someone robs your house physically rather than your identity or assets online .

prmoustache2• 10 months ago

Are we exactly sure a crime has been committed?

ricardobeat2• 10 months ago

Most likely several? Opening someone else’s correspondence is a criminal offense alone, regardless of what’s done with it

hoangtrannn• 10 months ago

I come for the thread but amazed with the website and beautiful UI of Koi platform. Looks really cool!

loloquwowndueo• 10 months ago

Modulo the “covers half the screen in mobile” annoying cookie pop up.

input_sh• 10 months ago

If only the text itself wasn't artifically padded with AI.

wiether• 10 months ago

We can only guestimate the impact:
1,500 downloads every single week
Being conservative, maybe 20% are actively in use
That's about 300 organizations
Each one probably sending what, 10-50 emails daily?
We're talking about 3,000 to 15,000 emails EVERY DAY flowing straight to giftshop.club

Those figures seems crazy to me.

They assert that behind a single download from NPM is a unique organization.

That's insane.

A download from NPM is just someone (most often something) doing _npm i_.

Given how most CIs are (badly) configured in the wild, they'll _npm i_ at least once per run. If not per stage.

So those 1,500 downloads per week can come from just 2 organizations, one with a dev POCing the tool, and one with a poorly configured CI.

And the official repo has 1 watch 0 fork and 2 stars: https://github.com/ActiveCampaign/postmark-mcp

Sure the issue raised around MCP and supply chain is big, but the actual impact of this one is probably close to 0.

zahlman4• 10 months ago

A download from NPM is just someone (most often something) doing _npm i_.
Given how most CIs are (badly) configured in the wild, they'll _npm i_ at least once per run. If not per stage.

Indeed. By the same calculus, it should take less than a year for everyone on the planet (including children and the elderly and a whole lot of people who might not have computers, let alone any idea what Python is) to get a personal copy of many of the most popular Python packages (https://pypistats.org/top).

jgalt2122• 10 months ago

First Malicious MCP in the Wild

First that you know of. MCP zero-days seems to be so much easier to find and exploit.

hn87262• 10 months ago

Seems like the package has been removed from npm: https://www.npmjs.com/package/postmark-mcp. Which is too bad, because there's no way to verify the claims from the article

c-linkage• 10 months ago

I'll say it again: no one cares about security.

First, no one is ever punished for having security breaches: companies outsource security specifically to avoid responsibility (using contract law to transfer risk). Second, the MBA mentality has infected software development such that first to market and feature velocity trumps all: if I can download a package or have an LLM write my code so much the faster than me writing it.

Security is fucked because shareholders want it that way. Change the incentives to make security matter if you want something different.

xpe6• 10 months ago

> I'll say it again: no one cares about security.
Readers are likely to ignore your prose or dismiss it as an uneducated rant when you make overgeneralizations. Learn how to avoid this error.

Writing Commons > Argumentation > Overgeneralization

https://writingcommons.org/section/genre/argument-argumentat...

Too• 10 months ago

Somehow, we've all just accepted that it's totally normal to install tools from random strangers

This has been the modus operandi since windows xp days where we in all innocence installed random cd-ripping software and bonzi buddies, with full access to the rest of the computer.

It’s hard to argue against convenience. People will always do what’s easy even if less secure. The bigger lesson is why we still haven’t learned to sandbox sandbox sandbox. Here it seems like AI just did a full factory reset on every best practice know to man.

zahlman4• 10 months ago

People will always do what’s easy even if less secure. The bigger lesson is why we still haven’t learned to sandbox sandbox sandbox.

Because nobody has figured out how to make sandboxing easy, apparently.

N.B. at this level, "easy" has to include "provided by default with the operating system".

Animats• 10 months ago

And that's a dumb attack. Not one that uses a LLM to find the good stuff, and transmit it through some covert channel to somewhere the attacker can get it.

Illniyar• 10 months ago

This doesn't look like an MCP backdoor. It looks like a supply chain attacks on an unofficial mcp tool.

It's definitely not what we are worried about with MCP.

kordlessagain2• 10 months ago

This is the comment on here that matters. Supply chain attacks happen all the time. Malicious PyPI packages being one classic example.

This is not about how stupid MCP is, it's about how stupid people can be. And anyone mucking about with agentic workflows, through contractors or not, should be responsible for the code their machines run. Period.

nubg• 10 months ago

The content of this article is good, but why send it through ChatGPT AI sloppification?

I'd rather just read whatever the prompt was. In the current state it's an insult to the user and a waste of time.

sixhobbits• 10 months ago

Reall glad to hear it's obvious to you too because I hate it, and it seems from asking some friends etc that they don't notice or can't tell.

hmcamp• 10 months ago

How did you identify that it was AI-slopified? This missed me.

BinaryIgor• 10 months ago

I wonder whether there isn't even more backdoors of this kind in various popular packages for all kinds of programming languages - after all, it seems like security scrutiny for developer-level packages is something that we are just starting to get that might be important

tnolet• 10 months ago

This blogpost is almost impossible to read. Might be AI augmented. So many unnecessary sentences and embellishments.

Shame, the actual topic is interesting

Tractor8626• 10 months ago

Looks like bcc was added for debugging and was not removed before commit.

Too obvious for backdoor. Replacing bitcoin addresses in email would be more useful)

EdwardDiego2• 10 months ago

I suspect it was added by the LLM that wrote this MCP.

EdwardDiego2• 10 months ago

At the risk of giving too much value benefit of the doubt, maybe an LLM put that BCC in to debug failures and well, it's hard to PR code you have no mental model of.

Aeolun• 10 months ago

Maybe the developer didn’t actually do this on purpose? I sometimes leave debug code in by accident when I publish as well. It happens. A bcc in plain sight seems like debug to me.

franky47• 10 months ago

The reaction (removing the package) is also similar to an inexperienced developer when confronted to their first vulnerability report.

Assuming good intentions (debugging) rather than malice was at play, communication is key: drop the malicious version of the package, publish a fix, and communicate on public channels (blog post, here on HN, social media) about the incident.

A proper timeline (not that AI slop in the OP article) also helps bring back trust.

m4tthumphrey• 10 months ago

I came here to say this too. I’m really not sure he’d leave his very public personal email in there in purpose. I am not ashamed to say I still use my personal Gmail for testing in 2025.

By the way, this is not specific to MCP, could have happened to any package.

andris9• 10 months ago

I maintain the Nodemailer library. Several years ago I used my personal email in a few usage examples. Developers still copy that old snippet, add their SMTP credentials and send test emails - which land in my inbox.

livejamie• 10 months ago

Wouldn't they notice a shitload of private emails coming in and publicly apologize/announce what happened as soon as possible?

gregorymichael• 10 months ago

Agreed. When building an app that sends email, bcc-ing yourself is an unreasonably effective logging mechanism.

esafak• 10 months ago

The attacker took the legitimate code from their repo, added his malicious BCC line, and published it to npm under the same name.

Why does npm allow packages to share names? Why does it not warn the user that they probably wanted another package? These are easy-to-solve problems.

layman512• 10 months ago

If I understand the situation correctly, the official solution does have the same name, but it's not published on npm.[0]

As far as I know, npm doesn't actually allow packages to share names if they are both going to be in the public registry.

[0] https://postmarkapp.com/blog/information-regarding-malicious...

slimebot80• 10 months ago

On a very basic level, ignoring the extreme examples ... I wonder how much these tools send back home.

It seems very hard to see what they are accessing. Let alone control it. We just rely on them asking when they see fit to ask.

The minute Zuck and Google start offering you things for free, you have to wonder sometimes.

I mean, forget about denying cookie popups in your browser . We are galaxies beyond.

jgalt2122• 10 months ago

This is probably a dumb question, but why are people using an MCP to send transactional emails? The email body might be LLM-generated for sure, but the sending of these seems very rinse / repeat straightforward.

queenss90• 10 months ago

I got a win last night and it was real, I played on the JO777 site

A Postmark backdoor that’s downloading emails

Related Stories