>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'?
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.
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.
The npm supply chain attacks (or any similar ones) are essentially the same issue described in the article. You can't trust 3rd-party provided code implicitly. Even if the code is initially fine it's subject to change in later revisions. This issue goes all the way down the stack. Obviously, with a large user base the likelihood of quick detection goes up, but the issue never goes away.
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.
It isn't just an RPC spec, it's a use case. Specs never exist without a reason. I can assure you, a spec is a lot of work to write. You don't do it unless there is a purpose.
And with MCP, that purpose is fundamentally unsafe. It cannot be done safely without a different underlying technology. So yeah, it's pretty fair to say MCP is unsafe by design. It wouldn't exist except for that desire to create systems which cannot be secure.
Sorry, I don’t understand. My understanding of what MCP is - is that it’s just a standard on how to provide tools/functions to LLMs to call. What those functions are, what they do, and what else happens when they’re called is - in my understanding - out of scope of MCP. To me MCP is literally a plumbing between black boxes, and plumbing cannot do anything about the safety of what happens outside of it. So to me MCP is not “safe” or “unsafe” - those terms are meaningless for a plumbing (as long, of course, as plumbing itself doesn’t somehow explode or connect somewhere it’s not supposed to or stuff like that). Do you mean the purpose and/or scope are different somehow?
> My understanding of what MCP is - is that it’s just a standard on how to provide tools/functions to LLMs to call.
That's exactly the point the GP was making: this is a fundamentally unsafe idea. It's impossible to allow an LLM to automatically run tools in a safe way. So yes, MCP as means to enable this fundamentally unsafe use case is fundamentally unsafe.
My point is that the term “safe” is not a good one. In context of the article it erodes the scope of what MCP is and what it does (bringing way more stuff into the picture) and misattributes issue.
MCP safety is stuff like access controls, or lack of vulnerabilities on the protocol level (stuff like XML entity bombs). Software behavior of what MCP bridges together is not MCP anymore.
People discovering and running malware believing it’s legit is not a MCP problem. This line of thought is based on that “P” stands for “protocol” - MCP is interface, not implementation. And it’s humans who pick and connect programs (LLMs and MCP servers), not technology.
I thought about it, and I think I know what the confusion could possibly be about.
To me, postmark-mcp is not a part of MCP, it’s a black box that talks MCP on one end. And its behavior is not an MCP but software trust and distribution issue, not specific to MCP (just like running any executables from random sources). I guess others may see differently.
> 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.
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.
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.
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.
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.
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.
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.
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!!?!
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.
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.
That's because people in general are good. They don't understand that there is a small fraction of humanity that would happily erase their digital lives given half a chance because they themselves can not even conceive of someone doing a thing like that.
The fact that we all can is a professional deformation, it is not normal. I lived in a place where the doors had no locks. Nobody could imagine anybody stealing from someone else's house. And so it just didn't happen. When buying the house there is the moment where the keys are transferred. The sellers somewhat sheepishly announced they didn't have any. The lawyer handling the transaction asked if they had lost their keys and if they did that they should pay for replacing the locks. Then it turned out they never had any locks in the first place and that this was pretty much the norm there.
That distrust that we call common sense is where we go wrong, the fact that we've connected the whole world means that these little assholes now have access to everything and everybody and there isn't even a good way to figure out who they are and how to punish them unless they are inept at hiding their traces.
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.
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 :-)
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.
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.
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.
> 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).
> 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.
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.
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.
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.
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.
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.
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.
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.
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
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
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.
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
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.
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
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.
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 .
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.
> 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.
> 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.
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...
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?
And cosmic rays could cause bit flips, causing a patient record to have an undetectable error, leading to a surgeon removing the wrong kneecap.
I’m exaggerating to make a point here. If one builds a threat model, one can better allocate one’s attention to the riskiest components.
All of us operate in an uncertain world. Flattening this into “it is all a mess” isn’t useful.
Saying “machines are dangerous” or “we all die sometimes” isn’t fitting after Randall is maimed and pulverized from a preventable industrial accident where the conveyer belt dragged him into a box forming machine. Randall should not
wear long sleeves. Randall should not have disabled the “screaming means something has gone wrong” sensors. Randall should not run the system at 5X speed while smoking meth.
That's not a popular opinion to express these days.
If you point out the excessive length, the rhetorical flaws, and the obvious idiomatic tics of AI writing people don't tend to want to hear it.
When authors had to do the work, you'd notice your article approaching 1900 words and feel the natural need to cut redundant platitudes like this:
> The postmark-mcp backdoor isn't just about one malicious developer or 1,500 weekly compromised installations. It's a warning shot about the MCP ecosystem itself.
An AI feels no such need, and will happily drag their readers through a tiresome circuitous journey.
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?
Malicious to me is intent. Microsoft does not store my emails to snoop or to potentially steal my assets. It Is a side effect of the systems they have created to ease user friction.
Some might argue that they want my data or behaviour (which is snooping) but exactly what has been said, my subscription fee is the value they extract from me and their enterprise value is the stickiness and the experience they provide.
To be clear, I am not a Microsoft fan, but I think it is safe to assume that Microsoft would not scrape my crypto wallets or bank account information to steal the entirety of my liquid assets. I can’t say the same for actors that plunk in a rogue email address to BCC themselves.
I have no idea how far the crew at Microsoft or any other large tech giant is willing to go into the grey area, but I can tell you they won’t attempt to drain my bank account without providing SOME kind of value to me in return.
No. The benefits to Microsoft from taking my business emails are negligible compared to their revenues. That’s not the case for an individual with malicious intent.
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.
As I mentioned above. I do not like Microsoft, but there is a difference of intention. In your over-characterization, you forget the fact that they provide product/services to users. Regardless of their strategies and how they build their bottom line, they provide users something in exchange for money. Regardless if the thing they provide has far reaching consequences or happens to be built for better fingerprinting, it’s been long enough of this that informed users know the trade offs.
I am so shocked at the amount of people that think someone who wants to siphon your livelihood in a parasitic fashion is equivalent to a corporation that you have to conceivably opt into using. Users can make choices in the products they use. This person injected themselves as a man in the middle in user’s lives. Completely different circumstances and not at all the same intention.
>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'?
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.
> 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.
It was even worse than that. It was basically an ad for a security product.
dogfood.ai?!
That's a really heartwarming story. Thanks.
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.
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.
The npm supply chain attacks (or any similar ones) are essentially the same issue described in the article. You can't trust 3rd-party provided code implicitly. Even if the code is initially fine it's subject to change in later revisions. This issue goes all the way down the stack. Obviously, with a large user base the likelihood of quick detection goes up, but the issue never goes away.
> 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.
It isn't just an RPC spec, it's a use case. Specs never exist without a reason. I can assure you, a spec is a lot of work to write. You don't do it unless there is a purpose.
And with MCP, that purpose is fundamentally unsafe. It cannot be done safely without a different underlying technology. So yeah, it's pretty fair to say MCP is unsafe by design. It wouldn't exist except for that desire to create systems which cannot be secure.
Sorry, I don’t understand. My understanding of what MCP is - is that it’s just a standard on how to provide tools/functions to LLMs to call. What those functions are, what they do, and what else happens when they’re called is - in my understanding - out of scope of MCP. To me MCP is literally a plumbing between black boxes, and plumbing cannot do anything about the safety of what happens outside of it. So to me MCP is not “safe” or “unsafe” - those terms are meaningless for a plumbing (as long, of course, as plumbing itself doesn’t somehow explode or connect somewhere it’s not supposed to or stuff like that). Do you mean the purpose and/or scope are different somehow?
> My understanding of what MCP is - is that it’s just a standard on how to provide tools/functions to LLMs to call.
That's exactly the point the GP was making: this is a fundamentally unsafe idea. It's impossible to allow an LLM to automatically run tools in a safe way. So yes, MCP as means to enable this fundamentally unsafe use case is fundamentally unsafe.
My point is that the term “safe” is not a good one. In context of the article it erodes the scope of what MCP is and what it does (bringing way more stuff into the picture) and misattributes issue.
MCP safety is stuff like access controls, or lack of vulnerabilities on the protocol level (stuff like XML entity bombs). Software behavior of what MCP bridges together is not MCP anymore.
People discovering and running malware believing it’s legit is not a MCP problem. This line of thought is based on that “P” stands for “protocol” - MCP is interface, not implementation. And it’s humans who pick and connect programs (LLMs and MCP servers), not technology.
You’re correct. MCP is just a defined way of mapping string descriptions to functions.
I thought about it, and I think I know what the confusion could possibly be about.
To me, postmark-mcp is not a part of MCP, it’s a black box that talks MCP on one end. And its behavior is not an MCP but software trust and distribution issue, not specific to MCP (just like running any executables from random sources). I guess others may see differently.
Right but you have a good security posture and hygiene. MCP as a use case (not a protocol) is encouraging risky usage by less security minded people.
Do people outside the HN audience exist that are using MCP servers?
Well, yes but they are not less nerd (actually, HN audience is not like it used to be, too)
> 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.
> 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.
> 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.
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.
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.
> 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.
Surely giving an unpredictable AI access to your system has absolutely no downsides at all.
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.
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.
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.
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!!?!
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.
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.
That's because people in general are good. They don't understand that there is a small fraction of humanity that would happily erase their digital lives given half a chance because they themselves can not even conceive of someone doing a thing like that.
The fact that we all can is a professional deformation, it is not normal. I lived in a place where the doors had no locks. Nobody could imagine anybody stealing from someone else's house. And so it just didn't happen. When buying the house there is the moment where the keys are transferred. The sellers somewhat sheepishly announced they didn't have any. The lawyer handling the transaction asked if they had lost their keys and if they did that they should pay for replacing the locks. Then it turned out they never had any locks in the first place and that this was pretty much the norm there.
That distrust that we call common sense is where we go wrong, the fact that we've connected the whole world means that these little assholes now have access to everything and everybody and there isn't even a good way to figure out who they are and how to punish them unless they are inept at hiding their traces.
Speak for yourself.
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.
https://xkcd.com/1053/
Today, 10,000 Americans discovered that water is wet for the first time. Same thing tomorrow.
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
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 :-)
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.
> 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.
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.
I recall the noted Zuckerberg comments regarding the situation you describe of why people are willing to trust you with their privacy and data...
> 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.
> 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).
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.
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.
How did you identify that it was AI-slopified? This missed me.
> 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.
> 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".
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...
This blogpost is almost impossible to read. Might be AI augmented. So many unnecessary sentences and embellishments.
Shame, the actual topic is interesting
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.
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.
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.
nah bro you got it wrong
its the other way around, codex started with TS then rewrite it to rust
I know. But why keep distributing over npm?
because JS user would cry why codex is gone from npm
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.
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.
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.
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
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.
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
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
Yeah, this was the case before MCPs as well. Especially with some of the really bloated SDKs (looking at you Firebase and Twilio).
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.
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.
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)
I suspect it was added by the LLM that wrote this MCP.
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
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.
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
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.
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 .
Are we exactly sure a crime has been committed?
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.
Perhaps. Or perhaps not. What are the likely consequences when this happens? Plausible deniability might work here -- and it might even be true.
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.
>> 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...
I come for the thread but amazed with the website and beautiful UI of Koi platform. Looks really cool!
If only the text itself wasn't artifically padded with AI.
Modulo the “covers half the screen in mobile” annoying cookie pop up.
> 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.
> 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.
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...
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?
And every distro has a different mix of packages that they install by default. There's no "standard" linux installation.
And cosmic rays could cause bit flips, causing a patient record to have an undetectable error, leading to a surgeon removing the wrong kneecap.
I’m exaggerating to make a point here. If one builds a threat model, one can better allocate one’s attention to the riskiest components.
All of us operate in an uncertain world. Flattening this into “it is all a mess” isn’t useful.
Saying “machines are dangerous” or “we all die sometimes” isn’t fitting after Randall is maimed and pulverized from a preventable industrial accident where the conveyer belt dragged him into a box forming machine. Randall should not wear long sleeves. Randall should not have disabled the “screaming means something has gone wrong” sensors. Randall should not run the system at 5X speed while smoking meth.
Bait article with an awful chatgpt generated image at the top to boot.
How is it “bait”? It’s covering a fairly brazen supply chain attack, what were you expecting?
Perhaps not something displaying every hallmark of an AI-generated article.
That's not a popular opinion to express these days.
If you point out the excessive length, the rhetorical flaws, and the obvious idiomatic tics of AI writing people don't tend to want to hear it.
When authors had to do the work, you'd notice your article approaching 1900 words and feel the natural need to cut redundant platitudes like this:
> The postmark-mcp backdoor isn't just about one malicious developer or 1,500 weekly compromised installations. It's a warning shot about the MCP ecosystem itself.
An AI feels no such need, and will happily drag their readers through a tiresome circuitous journey.
And the best part? Opening paragraphs with questions.
// Where did the machines learn this? LinkedIn influencers?
> First Malicious MCP in the Wild
First that you know of. MCP zero-days seems to be so much easier to find and exploit.
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?
Microsoft Servers != Malicious Actors Computer
> 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?
> How do you define “malicious”?
Malicious to me is intent. Microsoft does not store my emails to snoop or to potentially steal my assets. It Is a side effect of the systems they have created to ease user friction.
Some might argue that they want my data or behaviour (which is snooping) but exactly what has been said, my subscription fee is the value they extract from me and their enterprise value is the stickiness and the experience they provide.
To be clear, I am not a Microsoft fan, but I think it is safe to assume that Microsoft would not scrape my crypto wallets or bank account information to steal the entirety of my liquid assets. I can’t say the same for actors that plunk in a rogue email address to BCC themselves.
I have no idea how far the crew at Microsoft or any other large tech giant is willing to go into the grey area, but I can tell you they won’t attempt to drain my bank account without providing SOME kind of value to me in return.
Put simply, to Microsoft, my company’s continued business is worth more to them than my company’s nefariously-gotten email are.
The chance that they become a hostile actor to my business is effectively zero. Certainly among the lowest chances of any email provider.
> The chance that they become a hostile actor to my business is effectively zero.
I guess the same holds for this malicious (?) single developer.
No. The benefits to Microsoft from taking my business emails are negligible compared to their revenues. That’s not the case for an individual with malicious intent.
Microsoft Servers === Malicious Actors Computer because both are doing exactly the same thing, copying your e-mails to their servers.
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.
As I mentioned above. I do not like Microsoft, but there is a difference of intention. In your over-characterization, you forget the fact that they provide product/services to users. Regardless of their strategies and how they build their bottom line, they provide users something in exchange for money. Regardless if the thing they provide has far reaching consequences or happens to be built for better fingerprinting, it’s been long enough of this that informed users know the trade offs.
I am so shocked at the amount of people that think someone who wants to siphon your livelihood in a parasitic fashion is equivalent to a corporation that you have to conceivably opt into using. Users can make choices in the products they use. This person injected themselves as a man in the middle in user’s lives. Completely different circumstances and not at all the same intention.
Two wrongs do not make a right