[HN Gopher] Damn Vulnerable MCP Server
___________________________________________________________________
Damn Vulnerable MCP Server
Author : mrxhacker99
Score : 220 points
Date : 2025-04-16 16:00 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| latchkey wrote:
| This is far too complex. Let's start with just acknowledging the
| basic examples [0].
|
| [0] https://github.com/modelcontextprotocol/servers/issues/866
| ramon156 wrote:
| What a weird thread. Who posts an AI prompt as a source of
| truth
| gs17 wrote:
| The sentence "Even AI gets it right..." implies they do not
| think it's a source of truth, they think it's embarrassing
| for it to get it right and a human not to.
| lbeurerkellner wrote:
| Original author of some of the initial security notes at
| Invariant Labs here. Some resources, if you want to learn about
| MCP security:
|
| * Initial Security Note describing Tool Poisoning, Rug Pulls,
| Tool Shadowing for the first time with diagrams and detailed
| experiments: https://invariantlabs.ai/blog/mcp-security-
| notification-tool...,
|
| * Attack on WhatsApp MCP (both tool poisoning but also take-over
| via an infected message to your account):
| https://invariantlabs.ai/blog/whatsapp-mcp-exploited
|
| * BrowserMCP attack, where it suffices for the agent to visit a
| compromised website (https://access.invariantlabs.ai):
| https://x.com/lbeurerkellner/status/1912145060763742579
|
| We also recently released a security scanning tool to detect and
| prevent such attacks, including upcoming support for full
| proxying and local security scanning of tool calling payload and
| responses.
|
| Please have a look and provide feedback if you can:
| https://github.com/invariantlabs-ai/mcp-scan
| macinjosh wrote:
| Imagine using a hammer that can be set to hit your thumb instead
| of the nail. That's kinda like using MCP.
| gsibble wrote:
| Accurate.
| kiitos wrote:
| There seems to be a fundamental misunderstanding at play here.
|
| The MCP spec makes it pretty clear that MCP servers are expected
| to be run in environments that are implicitly trusted/trustable
| for any client that can reach them. This is clear from the
| default/assumed stdio transport, but even with SSE the protocol
| expects auth to be already-solved.
|
| In short, MCP servers are _not meant to be accessible as public
| APIs_ -- as ChatGPT puts it, MCP assumes that its transport is
| inherently trusted. It doesn 't seem like this is widely
| understood.
| eddythompson80 wrote:
| As it has been mentioned before, MCP isn't "vulnerable". It's
| just on the other side of your air lock. Think of your MCP as a
| different client application. The whole thing is just a client.
| The fact that you need to write a client for your client is....
| something, but your MCP app is a client app. It's boundaries with
| your service should be understood as such.
|
| Saying MCP is vulnerable is like saying "Web applications are
| vulnerable. Anyone can see the API calls you're making and modify
| them or trick your UI app to make a different call and hack your
| system". Obviously that's mostly nonsense, but not 100% wrong
| either. You see it a lot with very very inexperienced developers
| who think "just because my App is Android/iOS only I don't need
| to worry about authn/authz". There was just a story on here few
| weeks ago about some New Zealand startup that did that
| simonw wrote:
| The MCP ecosystem right now actively encourages insecure
| behavior. Just installing a popular WhatsApp sever can give
| attackers access to your private data - they can text you with
| instructions for your assistant to forward private messages to
| another account using tricks to help make that action look
| legit so you'll approve it:
| https://simonwillison.net/2025/Apr/9/mcp-prompt-injection/#m...
| eddythompson80 wrote:
| But you can replace MCP with any tech and you have the same
| valid sentence.
|
| "Attackers are using (email attachments, SMSs, TeamViewer,
| crypto wallet, phishing websites, etc) to access your private
| data - they can [...] you using tricks to make it seem legit"
|
| The only difference is that AI/MCP is the current flavor of
| the month for this type of attacks. These attacks get much
| worse when the tech has the hype (like AI now or limewire 20
| years ago or the internet 30 years ago) and the average user
| still doesn't quite fully grasp what this tech is doing or
| how it's working.
| anamexis wrote:
| I somewhat agree, but I think an important distinction is
| that in this case, you are legitimately giving the MCP
| server your credentials - there are no tricks there.
|
| This is distinct from various forms of phishing where they
| are tricking you to give access to sensitive information.
| Here, you are giving that access willingly to something
| that is then itself vulnerable to being tricked/tricking
| you.
| ilrwbwrkhv wrote:
| I think the JavaScript world has given up on all of these
| secure behaviors a long time back. Just look at Next.js
| lazystar wrote:
| > The fact that you need to write a client for your client
| is...
|
| correct me if im wrong, but isnt that a proxy? why is everyone
| calling it a server
| mooreds wrote:
| Yes! It's a proxy that might modify results on the way in or
| out, which proxies can do.
|
| Could also be called a gateway, which feels a bit more
| accurate.
|
| The same way API gateways perform additional services like
| rate-limiting and authentication and billing, an MCP gateway
| abstracts the services behind it and adds context such that
| an LLM can more easily interact with them.
| cyanydeez wrote:
| in this case, people are arguing it's a MITM attack,
| obscured by the MCP
| puliczek wrote:
| Damn, great work. I just added it to
| https://github.com/Puliczek/awesome-mcp-security to reach more
| people :)
___________________________________________________________________
(page generated 2025-04-17 23:02 UTC)