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.
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.
Idk, I think Microsoft could get away with a lot. Not selling your emails to the highest bidder, that might be a bridge too far, but training an LLM on Outlook emails? Probably. Just have an LLM scan every email to see if its contents are mundane or secret first, and only use the mundane ones. There might be a scandal of some sort, then Microsoft would say sorry (but keep the model), and then everyone would move on because the switching costs are too high.
"Not really true"?! TRUE AS HELL! "Outlook New" LITERALLY DOES THAT! It's an infostealer. Microsoft gets your login info and downloads your mails, contacts and calenders to its own servers!
How this app is legal and not marked as malware is beyond me! It's the biggest information heists in history!
Do people actually choose to use Outlook if they're not already forced to use Exchange/Office365, usually for work?
In my experience, it's hands down the worst e-mail client I've ever used. I only have it on my work PC because my employer uses Office 365. It never even crossed my mind to try to use it for my personal e-mailing needs.
I do agree, however, that companies that decide to trust MS don't care one bit about their scandalous practices. I don't even think it's as much of an actual choice as a cop-out, as in "everybody uses microsoft", so they rarely actually ponder the decision.
Outlook New gets installed by default on Windows 11. Of course people gonna use it. Even if they just trial it, their data is gone. A Anti-Virus should stop the software from running. But that will never happen.
> "everybody uses microsoft", so they rarely actually ponder the decision.
Exactly. That is my main argument against PantaloonFlames's claim "They have legitimate revenue at stake. If they betray trust on such a scale, and we find out, they'll be out of business."
At a certain scale nothing matters anymore! You can Bluescreen half the planet and still be in business.
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.
Giving AI agents permission to do things on your behalf in your computer is obviously dangerous. Installing a compromised MCP server is really the same as installing any compromised software. The fact that this software is triggered by the user or an agent doesn't really change anything. I don't think that humans are more able to decide not to use a tool that could potentially be compromised, but that they have chosen to install already.
> 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.
> 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.
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).
The best way I can describe it is chatgpt has an urgent salesman like quality to its text. It adds words and sentences that have no informational content but instead are used to increase the emotional weight of the text.
Multiple "it's not X, it's Y" and weirdly heavy use of dashes (it looks like the person who posted this did a find-and-replace to turn em-dashes into hyphens to try to mask that).
That said, I didn't find this one too bad. I could be wrong but it feels to me like the author had already written this out in their own words and then had the AI do a rewrite from that.
I personally became suspicious about this article being written with the help of LLMs when I read, "Day after day. Week after week." This is pretty far down in the article, but it felt weird to read this because it was near the end of that paragraph that its in. It felt repetitive, and then the paragraph right after that has the classic LLM pattern where they write, "it's not just X, it's Y."
This is what I noticed before deciding it seemed too much like AI to be worth reading more:
"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.
[...]
On paper, this package looked perfect. The developer? Software engineer from Paris, using his real name, GitHub profile packed with legitimate projects. This wasn't some shady anonymous account with an anime avatar. This was a real person with a real reputation, someone you'd probably grab coffee with at a conference.
[...]
One single line. And boom - every email now has an unwanted passenger.
[...]
Here's the thing - there's a completely legitimate GitHub repo with the same name"
"Here's the thing", dashes - clearly the operator was aware how much of a giveaway em dashes are and substituted them but the way they're used here still feels characteristic - and this pattern where they say something with a question mark? And then elaborate on it. Also just intangibles like the way the sentences were paced. I wouldn't bet my life on it, but it felt too much like slop to pay attention to.
I genuinely take the effort to write em dashes quite often, certainly in formal documents or publications. So for me that's not a tell-tale sign of AI usage. Your analysis of the pacing of the article on the other hand — spot on.
>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.
> You can't trust 3rd-party provided code implicitly.
But that is what (almost) all of us do.
There is debate about this the rust world, where there are mitigations that very few even aware of
Mostly rusticans block their ears, close their eyes, and pretend everything will be just peachy
Until some ordinary developer develops a crypto wallet in Rust, honestly, that steals money for a third party this will not be addressed. Even then...
This is a big problem and we need to make everybody aware that they can protect themselves, and make them Liable for not taking those steps, before that happens
Almost every developer outside the defense and aerospace sector is just stuffing code from internet randos into their binaries, JARs, and wheels. Just after they run this code on their developer machine that they keep their SSH keys on. It's a wonder/mystery/miracle we're not all hacked all day every day. The Rust and JS worlds are especially bad because somehow people got it into their heads that more dependencies are better. Why write 5 lines of your own code when you can use a dependency? (This is a real example of a discussion I've had at work)
Ah, I see. True. In my case I am looking forward to setting up a Linux workstation where I will severely limit random access to my system (and $HOME) via various means i.e. Flatpak and others. $HOME/.ssh is definitely first on the list.
But I agree that the out-of-the-box settings really make you wonder how we are not indeed hacked all day every day.
> 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.
yes. Previously that idiot had to write code. Now it's the LLM that is directing invocation of these functions. And the LLM is a coding prodigy with the judgment of a 3 year old kid.
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.
MCPs are just fancy wrappers over rest apis, at least majority of the MCP servers out in the market are like that.
Having an MCP necessarily does not mean it is unsafe until and unless the company rushed execution and released something which it should not have in the first place.
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.
Not an XML bomb, but... at the protocol level, AFAIK, MCP allows the server to change its list of tools and what they do, and the description of what they do, at any point. The chatbot when it starts up, calls "tools/list" and gets a list of tools. So, if "approval for use" depends on that data, .. the approval is built on something that can shift at any time.
That, coupled with dynamic invocation driven by the LLM engine, seems like a security problem at the protocol level.
-----
Contrast to connecting an agent to a service that is defined by a spec. In this hypothetical world, I can tell my agent: "here's the spec and here's the endpoint that implements it". And then my agent will theoretically call only the methods in the spec. The endpoint may change, my spec won't.
I still need to trust the endpoint; that it's not compromised. Maybe I'm seeing a difference where there is none.
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.
I was more referring to the environment that MCP servers run within, which at the end of the day is simply a massive interpolated string that blends instructions and data/content together in a way that an LLM will do its best to figure out a helpful response.
A 'perfectly secured' MCP server will become insecure simply by existing along neighbouring, insecure, tools. With that, I think it's safe to take a broader, less technical definition and say that you should use AI agents + MCP servers with caution.
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.
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.
> SQL injection attacks are an example of the age old issue of mixing up input and instructions.
Yes, and attacks on AI are much the same. The AI gets "prompted" by something that was supposed to be inert processable data. (Or its basic conduct guidelines are overridden because the system doesn't and can't distinguish between the "system prompt" and "user prompt".)
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.
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.
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.
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.
I disagree, writing your own code is the only thing that does scale. Even if you do nothing more than take the NPM package get source, and then do your own maintenance on it. But having been in different organizations that chose one path or the other, the durable organizations chose to write their own code.
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.
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!!?!
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.
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.
When I was growing up, we did not have a key to lock our house. I was a "latch key kid", both parents worked, but I never had a key. I remember meeting someone who locked their front door as a matter of course, and thinking that was so curious.
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.
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.
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.
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.
There's something deeply ingrained in the American psyche that says that warnings and guardrails are for other, stupid people. You, personally, are no doubt an ubermensch who can perform every procedure flawlessly from memory every time. If there were a crisis you would be a hero and save everyone. This applies equally to "good guy with a gun" and human factors analysis of software.
I'm sorry, we fundamentally disagree and there is no point in arguing as it is completely off-topic and our minds are made up. Your comment is unnecessarily inflammatory as is the OC's; the thread about MCP servers and their security model.
> 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.
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
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.
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.
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.
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.
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
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.
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.
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 .
For that you need to be positive the mails aren't going to /dev/null on the remote server and they just count the mails received.
For all we know it could have been a research to figure out on how easy is it to introduce a change like that and how much time such a redirection can be gone unnoticed.
It is just a piece of code in a random library available to download and used by persons actually willing and deciding to use it. The code was free to read before and after downloading it. No intrusion has been done on a remote machine, not even a phishing email have been sent.
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.
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
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
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.
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.
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.
> 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.
> 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.
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?
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.
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.
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.
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.
> 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.
Idk, I think Microsoft could get away with a lot. Not selling your emails to the highest bidder, that might be a bridge too far, but training an LLM on Outlook emails? Probably. Just have an LLM scan every email to see if its contents are mundane or secret first, and only use the mundane ones. There might be a scandal of some sort, then Microsoft would say sorry (but keep the model), and then everyone would move on because the switching costs are too high.
Why would selling your emails to the highest bidder be a bridge too far? Your ISP already could sell all the data they have on you that way…
Sounds like Ramp ha
> If they betray trust on such a scale, and we find out, they'll be out of business.
Provably false. Google has been found to lie about data collection for years and they still have more money than ever.
"Not really true"?! TRUE AS HELL! "Outlook New" LITERALLY DOES THAT! It's an infostealer. Microsoft gets your login info and downloads your mails, contacts and calenders to its own servers!
How this app is legal and not marked as malware is beyond me! It's the biggest information heists in history!
https://www.heise.de/en/news/Microsoft-lays-hands-on-login-d... https://cybernews.com/privacy/new-outlook-copies-user-emails...
> If they betray trust on such a scale, and we find out, they'll be out of business.
The decision makers don't care. They could eat children and they still would buy from them.
https://www.wiz.io/blog/storm-0558-compromised-microsoft-key...
Do people actually choose to use Outlook if they're not already forced to use Exchange/Office365, usually for work?
In my experience, it's hands down the worst e-mail client I've ever used. I only have it on my work PC because my employer uses Office 365. It never even crossed my mind to try to use it for my personal e-mailing needs.
I do agree, however, that companies that decide to trust MS don't care one bit about their scandalous practices. I don't even think it's as much of an actual choice as a cop-out, as in "everybody uses microsoft", so they rarely actually ponder the decision.
Outlook New gets installed by default on Windows 11. Of course people gonna use it. Even if they just trial it, their data is gone. A Anti-Virus should stop the software from running. But that will never happen.
> "everybody uses microsoft", so they rarely actually ponder the decision.
Exactly. That is my main argument against PantaloonFlames's claim "They have legitimate revenue at stake. If they betray trust on such a scale, and we find out, they'll be out of business."
At a certain scale nothing matters anymore! You can Bluescreen half the planet and still be in business.
What do you recommend businesses use instead?
Of course. I should have added “if they wanted to” and there is almost no rational reason that they would.
> 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.
Giving AI agents permission to do things on your behalf in your computer is obviously dangerous. Installing a compromised MCP server is really the same as installing any compromised software. The fact that this software is triggered by the user or an agent doesn't really change anything. I don't think that humans are more able to decide not to use a tool that could potentially be compromised, but that they have chosen to install already.
> 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.
> 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.
I recall the noted Zuckerberg comments regarding the situation you describe of why people are willing to trust you with their privacy and data...
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.
> 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.
> 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.
The best way I can describe it is chatgpt has an urgent salesman like quality to its text. It adds words and sentences that have no informational content but instead are used to increase the emotional weight of the text.
Multiple "it's not X, it's Y" and weirdly heavy use of dashes (it looks like the person who posted this did a find-and-replace to turn em-dashes into hyphens to try to mask that).
That said, I didn't find this one too bad. I could be wrong but it feels to me like the author had already written this out in their own words and then had the AI do a rewrite from that.
I guess you're not hanging around younger people who have made this part of normal speech?
I personally became suspicious about this article being written with the help of LLMs when I read, "Day after day. Week after week." This is pretty far down in the article, but it felt weird to read this because it was near the end of that paragraph that its in. It felt repetitive, and then the paragraph right after that has the classic LLM pattern where they write, "it's not just X, it's Y."
This is what I noticed before deciding it seemed too much like AI to be worth reading more:
"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.
[...]
On paper, this package looked perfect. The developer? Software engineer from Paris, using his real name, GitHub profile packed with legitimate projects. This wasn't some shady anonymous account with an anime avatar. This was a real person with a real reputation, someone you'd probably grab coffee with at a conference.
[...]
One single line. And boom - every email now has an unwanted passenger.
[...]
Here's the thing - there's a completely legitimate GitHub repo with the same name"
"Here's the thing", dashes - clearly the operator was aware how much of a giveaway em dashes are and substituted them but the way they're used here still feels characteristic - and this pattern where they say something with a question mark? And then elaborate on it. Also just intangibles like the way the sentences were paced. I wouldn't bet my life on it, but it felt too much like slop to pay attention to.
I genuinely take the effort to write em dashes quite often, certainly in formal documents or publications. So for me that's not a tell-tale sign of AI usage. Your analysis of the pacing of the article on the other hand — spot on.
They probably saw an em dash, an emoji, or a word that is not in their vocabulary
>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?!
This article was published few days ago citing notion's mcp server and it looks legit
https://www.codeintegrity.ai/blog/notion
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.
> You can't trust 3rd-party provided code implicitly.
But that is what (almost) all of us do.
There is debate about this the rust world, where there are mitigations that very few even aware of
Mostly rusticans block their ears, close their eyes, and pretend everything will be just peachy
Until some ordinary developer develops a crypto wallet in Rust, honestly, that steals money for a third party this will not be addressed. Even then...
This is a big problem and we need to make everybody aware that they can protect themselves, and make them Liable for not taking those steps, before that happens
What exactly are you talking about? Interested to learn more.
Almost every developer outside the defense and aerospace sector is just stuffing code from internet randos into their binaries, JARs, and wheels. Just after they run this code on their developer machine that they keep their SSH keys on. It's a wonder/mystery/miracle we're not all hacked all day every day. The Rust and JS worlds are especially bad because somehow people got it into their heads that more dependencies are better. Why write 5 lines of your own code when you can use a dependency? (This is a real example of a discussion I've had at work)
Ah, I see. True. In my case I am looking forward to setting up a Linux workstation where I will severely limit random access to my system (and $HOME) via various means i.e. Flatpak and others. $HOME/.ssh is definitely first on the list.
But I agree that the out-of-the-box settings really make you wonder how we are not indeed hacked all day every day.
> 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.
> Before AI...
yes. Previously that idiot had to write code. Now it's the LLM that is directing invocation of these functions. And the LLM is a coding prodigy with the judgment of a 3 year old kid.
> 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.
MCPs are just fancy wrappers over rest apis, at least majority of the MCP servers out in the market are like that.
Having an MCP necessarily does not mean it is unsafe until and unless the company rushed execution and released something which it should not have in the first place.
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.
Not an XML bomb, but... at the protocol level, AFAIK, MCP allows the server to change its list of tools and what they do, and the description of what they do, at any point. The chatbot when it starts up, calls "tools/list" and gets a list of tools. So, if "approval for use" depends on that data, .. the approval is built on something that can shift at any time.
That, coupled with dynamic invocation driven by the LLM engine, seems like a security problem at the protocol level.
-----
Contrast to connecting an agent to a service that is defined by a spec. In this hypothetical world, I can tell my agent: "here's the spec and here's the endpoint that implements it". And then my agent will theoretically call only the methods in the spec. The endpoint may change, my spec won't.
I still need to trust the endpoint; that it's not compromised. Maybe I'm seeing a difference where there is none.
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.
I was more referring to the environment that MCP servers run within, which at the end of the day is simply a massive interpolated string that blends instructions and data/content together in a way that an LLM will do its best to figure out a helpful response.
A 'perfectly secured' MCP server will become insecure simply by existing along neighbouring, insecure, tools. With that, I think it's safe to take a broader, less technical definition and say that you should use AI agents + MCP servers with caution.
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)
> 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.
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.
> SQL injection attacks are an example of the age old issue of mixing up input and instructions.
Yes, and attacks on AI are much the same. The AI gets "prompted" by something that was supposed to be inert processable data. (Or its basic conduct guidelines are overridden because the system doesn't and can't distinguish between the "system prompt" and "user prompt".)
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
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.
> 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.
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.
I disagree, writing your own code is the only thing that does scale. Even if you do nothing more than take the NPM package get source, and then do your own maintenance on it. But having been in different organizations that chose one path or the other, the durable organizations chose to write their own code.
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.
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!!?!
Surely giving an unpredictable AI access to your system has absolutely no downsides at all.
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.
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.
When I was growing up, we did not have a key to lock our house. I was a "latch key kid", both parents worked, but I never had a key. I remember meeting someone who locked their front door as a matter of course, and thinking that was so curious.
What country was this? I've heard of leaving house unlocked but never no locks at all
Northern Canada.
People are doing this with MCP on large scale, it's not talked about enough; otherwise sensible people are dismissive of the risks.
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.
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.
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.
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.
Speak for yourself.
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
[flagged]
Did you just desperately want to grind your political axe today? This has nothing to do with anything.
There's something deeply ingrained in the American psyche that says that warnings and guardrails are for other, stupid people. You, personally, are no doubt an ubermensch who can perform every procedure flawlessly from memory every time. If there were a crisis you would be a hero and save everyone. This applies equally to "good guy with a gun" and human factors analysis of software.
[flagged]
I'm sorry, we fundamentally disagree and there is no point in arguing as it is completely off-topic and our minds are made up. Your comment is unnecessarily inflammatory as is the OC's; the thread about MCP servers and their security model.
> 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
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
I got a win last night and it was real, I played on the JO777 site
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.
Agreed. When building an app that sends email, bcc-ing yourself is an unreasonably effective logging mechanism.
Wouldn't they notice a shitload of private emails coming in and publicly apologize/announce what happened as soon as possible?
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.
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.
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.
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).
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.
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.
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?
Most likely several? Opening someone else’s correspondence is a criminal offense alone, regardless of what’s done with it
For that you need to be positive the mails aren't going to /dev/null on the remote server and they just count the mails received.
For all we know it could have been a research to figure out on how easy is it to introduce a change like that and how much time such a redirection can be gone unnoticed.
It is just a piece of code in a random library available to download and used by persons actually willing and deciding to use it. The code was free to read before and after downloading it. No intrusion has been done on a remote machine, not even a phishing email have been sent.
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.
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.
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.
> 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.
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...
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
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
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...
> First Malicious MCP in the Wild
First that you know of. MCP zero-days seems to be so much easier to find and exploit.
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.
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.
My AI-dar must suck. Can you give details on how you detected AI usage? Was it just a vibe?
The big giveaways for me are overused idiomatic phrasing, and being unable to progress through a thesis and just circling the same idea over and over.
The "this isn't just a _____, it's a (adjective of magnitude) _____, _____, and ______" form is one of the most egregious I see everywhere.
And the best part? Opening paragraphs with questions.
// Where did the machines learn this? LinkedIn influencers?
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.
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.
> 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.
> 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.
[dead]
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?
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.
> 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.
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