[HN Gopher] The Postmark backdoor that's downloading emails
___________________________________________________________________
The Postmark backdoor that's downloading emails
Author : ghuntley
Score : 209 points
Date : 2025-09-27 14:23 UTC (8 hours ago)
(HTM) web link (www.koi.security)
(TXT) w3m dump (www.koi.security)
| hdjdndndba wrote:
| Bait article with an awful chatgpt generated image at the top to
| boot.
| nativeit wrote:
| How is it "bait"? It's covering a fairly brazen supply chain
| attack, what were you expecting?
| bonsai_spool wrote:
| Perhaps not something displaying every hallmark of an AI-
| generated article.
| oasisbob wrote:
| 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.
| Terretta wrote:
| And the best part? Opening paragraphs with questions.
|
| // Where did the machines learn this? LinkedIn
| influencers?
| akagusu wrote:
| The new Outlook app keeps a copy of all your e-mails, including
| your e-mail credentials, at Microsoft servers. Microsoft is doing
| this for months to millions of people and nobody cares. Why a
| single developer copying a couple hundreds of e-mails is such a
| big deal?
| two_handfuls wrote:
| Two wrongs do not make a right
| fathermarz wrote:
| Microsoft Servers != Malicious Actors Computer
| aleph_minus_one wrote:
| > 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?
| OtherShrezzing wrote:
| 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.
| aleph_minus_one wrote:
| > The chance that they become a hostile actor to my
| business is effectively zero.
|
| I guess the same holds for this malicious (?) single
| developer.
| OtherShrezzing wrote:
| 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.
| fathermarz wrote:
| > 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.
| anonym29 wrote:
| 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.
| fathermarz wrote:
| 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.
| akagusu wrote:
| Microsoft Servers === Malicious Actors Computer because both
| are doing exactly the same thing, copying your e-mails to
| their servers.
| AznHisoka wrote:
| Good thing i dont even wanna use any 3rd party libraries when
| using stuff like Postmark. Just old fashioned curl and POST
| requests to send emails with Postmark.
|
| And i consider myself a lazy person. Using 3rd party libraries
| are just more of a headache and time sink sometimes
| bfelbo wrote:
| Yeah, this was the case before MCPs as well. Especially with
| some of the really bloated SDKs (looking at you Firebase and
| Twilio).
| thepill wrote:
| I understand the problem mentioned with mcp servers but this kind
| of attack could happen to any external dependency (like a smtp
| package) i guess
| WD-42 wrote:
| 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.
| hn8726 wrote:
| The "postmark-mcp" from the article seems like some random
| guy's package though, postmark has its own official mcp
| server as well: https://postmarkapp.com/lp/mcp. It's like
| installing ublock extension but published by a 'coder3012'
| account
| jinwoo68 wrote:
| It's almost always npm packages. I know that's because npm is the
| most widely used package system and most motivating one for
| attackers. But still bad taste in my mouth.
| hendersoon wrote:
| This is why I don't run stdio MCP servers. All MCPs run on
| docker containers on a separate VM host on an untrusted VLAN
| and I connect to them via SSE.
|
| Still vulnerable to prompt injection of course, but I don't
| connect LMs to my main browser profile, email, or cloud
| accounts either. Nothing sensitive.
| greatgib wrote:
| 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.
| iagooar wrote:
| 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.
| tonyhart7 wrote:
| nah bro you got it wrong
|
| its the other way around, codex started with TS then rewrite
| it to rust
| iagooar wrote:
| I know. But why keep distributing over npm?
| tonyhart7 wrote:
| because JS user would cry why codex is gone from npm
| xpe wrote:
| 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.
| dpflan wrote:
| 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...
| xpe wrote:
| > Somehow, we've all just accepted that it's totally normal to
| install tools from random strangers that can
|
| _Some_ people do this without thinking much about it. Not all of
| us. This is not normal nor ok.
|
| Predicting this kind of attack was easy. Many of us probably did.
| (I did.) This doesn't make me feel much better though, since (a)
| I don't relish when lazy or ignorant people get pwned; (b) there
| are downstream effects on uninvolved people; and (c) there are
| classes of attacks that are not obvious to you or me.
|
| Stay suspicious, stay safe. There are sharks in the water. With
| frikin' laser beams on their heads too.
| ako wrote:
| 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...
| SoftTalker wrote:
| And every distro has a different mix of packages that they
| install by default. There's no "standard" linux installation.
| xpe wrote:
| 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.
| xpe wrote:
| I don't know where to start with the comment above. First,
| different code bases receive different levels of scrutiny, so
| factor this in. Second, there are tools that can help with
| supply chain security. Third, security isn't all or nothing;
| we can and do make decisions under uncertainty. Fourth, who
| is accountable when things go badly?
| mattxxx wrote:
| 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.
| xpe wrote:
| Perhaps. Or perhaps not. What are the likely consequences when
| this happens? Plausible deniability might work here -- and it
| might even be true.
| Dilettante_ wrote:
| >Well, here's the thing not enough people talk about: we're
| giving these tools god-mode permissions. Tools built by people
| we've never met. People we have zero way to vet. And our AI
| assistants? We just... trust them. Completely.
|
| I keep seeing this pattern in articles: "Did you _know_ that if
| you point the gun at your foot and pull the trigger, _yOu ShOoT
| yOuRsElF iN tHe FoOt??!?_ I couldn 't believe it myself!! What a
| discovery!!1!"
|
| Are people really this oblivious or are these articles written
| about non-issues just to have written 'content'?
| BobbyTables2 wrote:
| These also remind me on the early 1980s mentality of some who
| thought anything printed by a computer must be correct.
|
| It's an AI, it must be perfect! /s
| avs733 wrote:
| This is unfair. It presumes a universal understanding of
| something largely because it is obvious to us. Most computer
| users have little to know detailed understanding of how any
| computer technology works, and because they are invisible and
| abstract, even less understanding of the risks they expose
| themselves to.
|
| The answer to you gun analogy is false because it assumes basic
| knowledge of a gun. This is part of why so many kids shoot
| themselves or family members with guns - because they don't
| know if you pull the trigger something violent will happen
| until they are taught it.
| Dilettante_ wrote:
| 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.
| jacquesm wrote:
| 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.
| lazide wrote:
| 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!!?!
| ljm wrote:
| What's obvious to the audience of HN isn't necessarily obvious
| to anyone else.
|
| Articles like this are intended to serve the latter group of
| people.
|
| And it's true, AI agents with MCP servers are pretty much
| unsafe by design, because security was never considered from
| the start. Until that changes, if it ever even does, the best
| thing to do is to inform.
| didericis wrote:
| > the best thing to do is to inform.
|
| While also not using them yourself/actively trying to find
| and strip them out of workflows you have control over.
| dawnerd wrote:
| 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.
| lsaferite wrote:
| 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.
| drdaeman wrote:
| > 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.
| chowells wrote:
| 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.
| drdaeman wrote:
| 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?
| formercoder wrote:
| You're correct. MCP is just a defined way of mapping
| string descriptions to functions.
| drdaeman wrote:
| 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.
| bravura wrote:
| 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.
| tsimionescu wrote:
| > 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.
| drdaeman wrote:
| 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.
| askl wrote:
| Do people outside the HN audience exist that are using MCP
| servers?
| brazukadev wrote:
| Well, yes but they are not less nerd (actually, HN audience
| is not like it used to be, too)
| bsder wrote:
| > What's obvious to the audience of HN isn't necessarily
| obvious to anyone else.
|
| AI amplifies the problem.
|
| Before AI, the idiot who accidentally has too much access
| probably doesn't have the ability to actively exploit it.
|
| Given how much AI is being shoved down everybody's throats,
| an idiot with access now is an _attack vector_ because they
| are have neither the ability nor desire to vet anything the
| AI is feeding to them.
| kemayo wrote:
| 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.
| askl wrote:
| That's a really heartwarming story. Thanks.
| Aurornis wrote:
| > 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.
| ikiris wrote:
| It was even worse than that. It was basically an ad for a
| security product.
| smcin wrote:
| dogfood.ai?!
| m3047 wrote:
| There was a time when email clients running scripts in emails
| from randos on the internet was "a game-changing opportunity
| for automation". Here we are again.
|
| There was a time when people thought letting their children use
| the internet as a babysitter was healthier than parking them in
| front of the television... guess that turned out another way.
| zobzu wrote:
| The problem, especially with AI, IMO is that folks are even
| more willing to shoot themselves in the foot.
|
| IMO this might be due to a few things like these:
|
| 1. Folks are trained on buffer overflows and SQL injections,
| they don't even question it, these are "bad". But an MCP
| interface to an API with god-like access to all data? The MCP
| of course will make sure its safe for them! (of course, it does
| not). It's learning and social issue rather than a technical
| issue. Sometimes, it makes me feel like we're all LLMs.
|
| 2. 300 things to fix, 100 vendors, and it needs to be done
| yesterday. As soon as you look into the vendor implementation
| you find 10 issues, because just like you, they have 300 things
| to fix and it needs to be done yesterday, so trade-offs become
| more dangerous. And who's going to go after you if you do not
| look into it too hard? No one right now.
|
| 3. Complete lack of oversight (and sometimes understanding). If
| you're just playing around by prompting an LLM you do not know
| what its doing. When it works, you ship. We've all seen it by
| now. Personally, I think this one could be improved by having a
| visual scheduler of tasks.
| collinmcnulty wrote:
| I think the issue is that the security issue is inherent to the
| core story being told about AI. "It can read your emails and
| respond automatically" is both a pretty compelling story to
| certain people who aren't waist deep in tech news, and also
| exceedingly dangerous.
| flowerthoughts wrote:
| https://xkcd.com/1053/
|
| Today, 10,000 Americans discovered that water is wet for the
| first time. Same thing tomorrow.
| scuff3d wrote:
| Surely giving an unpredictable AI access to your system has
| absolutely no downsides at all.
| zahlman wrote:
| > Are people really this oblivious
|
| Last I checked, basic SQL injection attacks were still causing
| massive economic damage every year and are at or near the top
| of the OWASP list. SQL injection is essentially the result of
| unintentionally giving god-mode permission to a database by
| failing to understand how queries are built and processed.
| The... agency available to AI agents might not be all that
| obvious either.
| OptionX wrote:
| 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.
| kordlessagain wrote:
| Speak for yourself.
| Terr_ wrote:
| 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.
| ChuckMcM wrote:
| > 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.
| cyanydeez wrote:
| 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.
| afrisch wrote:
| 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 :-)
| SoftTalker wrote:
| Yeah I thought the same thing. This has nothing to do with MCP
| really, the same flaw is there in all software: you have to
| trust the author and the distributor. Nothing stops Microsoft
| from copying all your Outlook mail. Nothing stops Google from
| copying all your gmail. Nothing stops the Mutt project from
| copying all your email. Open source users like to think that
| "many eyes" keep the code clean and they probably do help,
| especially on popular projects where all commits get reviewed
| in detail, but the chance is still there. And the rest of us
| just trust the developers. This problem is as old as software.
| phatskat wrote:
| > 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.
| dpflan wrote:
| I recall the noted Zuckerberg comments regarding the situation
| you describe of why people are willing to trust _you_ with
| their privacy and data...
| EasyMark wrote:
| 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.
| everdrive wrote:
| > 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.
| ricardobeat wrote:
| What stops police/a prosecutor from getting a warrant for
| Squarespace/GoDaddy to give them info on the purchase of the
| giftclub.shop domain? Their payment method is identifiable, I
| doubt someone commiting this kind of attack is covering their
| traces very well.
| manquer wrote:
| 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 .
| prmoustache wrote:
| Are we exactly sure a crime has been committed?
| hoangtrannn wrote:
| I come for the thread but amazed with the website and beautiful
| UI of Koi platform. Looks really cool!
| loloquwowndueo wrote:
| Modulo the "covers half the screen in mobile" annoying cookie
| pop up.
| input_sh wrote:
| If only the text itself wasn't artifically padded with AI.
| wiether wrote:
| > 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.
| zahlman wrote:
| > 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).
| jgalt212 wrote:
| > First Malicious MCP in the Wild
|
| First that you know of. MCP zero-days seems to be so much easier
| to find and exploit.
| hn8726 wrote:
| Seems like the package has been removed from npm:
| https://www.npmjs.com/package/postmark-mcp. Which is too bad,
| because there's no way to verify the claims from the article
| c-linkage wrote:
| 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.
| xpe wrote:
| >> I'll say it again: no one cares about security.
|
| > Readers are likely to ignore your prose or dismiss it as an
| uneducated rant when you make overgeneralizations. Learn how to
| avoid this error.
|
| Writing Commons > Argumentation > Overgeneralization
|
| https://writingcommons.org/section/genre/argument-argumentat...
| Too wrote:
| > 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.
| zahlman wrote:
| > People will always do what's easy even if less secure. The
| bigger lesson is why we still haven't learned to sandbox
| sandbox sandbox.
|
| Because nobody has figured out how to make sandboxing easy,
| apparently.
|
| N.B. at this level, "easy" has to include "provided by default
| with the operating system".
| Animats wrote:
| And that's a dumb attack. Not one that uses a LLM to find the
| good stuff, and transmit it through some covert channel to
| somewhere the attacker can get it.
| Illniyar wrote:
| 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.
| kordlessagain wrote:
| This is the comment on here that matters. Supply chain attacks
| happen all the time. Malicious PyPI packages being one classic
| example.
|
| This is not about how stupid MCP is, it's about how stupid
| people can be. And anyone mucking about with agentic workflows,
| through contractors or not, should be responsible for the code
| their machines run. Period.
| nubg wrote:
| The content of this article is good, but why send it through
| ChatGPT AI sloppification?
|
| I'd rather just read whatever the prompt was. In the current
| state it's an insult to the user and a waste of time.
| sixhobbits wrote:
| Reall glad to hear it's obvious to you too because I hate it,
| and it seems from asking some friends etc that they don't
| notice or can't tell.
| hmcamp wrote:
| How did you identify that it was AI-slopified? This missed
| me.
| BinaryIgor wrote:
| I wonder whether there isn't even more backdoors of this kind in
| various popular packages for all kinds of programming languages -
| after all, it seems like security scrutiny for developer-level
| packages is something that we are just starting to get that might
| be important
| tnolet wrote:
| This blogpost is almost impossible to read. Might be AI
| augmented. So many unnecessary sentences and embellishments.
|
| Shame, the actual topic is interesting
| Tractor8626 wrote:
| 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)
| EdwardDiego wrote:
| I suspect it was added by the LLM that wrote this MCP.
| EdwardDiego wrote:
| 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.
___________________________________________________________________
(page generated 2025-09-27 23:00 UTC)