Damn Vulnerable MCP Server | Hacker News Reader

Damn Vulnerable MCP Server

github.com

227 pointsmrxhacker9963 comments

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

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...

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.

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.

I think the JavaScript world has given up on all of these secure behaviors a long time back. Just look at Next.js

It has caused a complete disaster to the entire software industry.

Would take decades to recover from that mistake that was JavaScript (and TypeScript)

> 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

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.

More here (not my post, someone I know wrote this): https://hookdeck.com/blog/mcp-gateway

in this case, people are arguing it's a MITM attack, obscured by the MCP

Yeah it is a proxy. I feel that in general we always use the term proxy as short for transparent proxy, while "server" is a bit more general purpose.

If you squint hard enough you can call almost any server a proxy. An FTP server is a proxy for data on disk. Github.com is a proxy for a git repo.

But yeah, saying "MCP is a proxy to your application" might be more insightful than "MCP is a client to your application"

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.

That concept has been replaced for years at this point with Zero Trust. A greenfield project intended to the "The Protocol" tm should never have been made with such a broken threat model.

This is such a boring perspective. Zero Trust is the spherical cow of trust models. When you do a DHCP request to your local DHCP server, you're trusting that local relationship implicitly. When you PPPoE (or whatever) to your ISP, you're trusting that client/server relationship. When you DNS lookup www.google.com you're trusting the global DNS infrastructure. It goes on and on and on. Every communication from client to server necessarily requires some amount of trust by the client in the server by definition.

We learn again and again: there are no totally trusted environments

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

This is far too complex. Let's start with just acknowledging the basic examples [0].

[0] https://github.com/modelcontextprotocol/servers/issues/866

What a weird thread. Who posts an AI prompt as a source of truth

Oh man you'd be shocked on Twitter. So many people have outsourced to AIs as arbiters of truth and reality. The number of "@grok is this true" "@perplexityai is this real" that pepper any post en masse is shocking and dismaying to me. In what I suppose shouldn't be a surprise but still stings, people seem to be offloading critical thinking and examination onto LLMs first, with usage as a tool for gathering context/additional points of research to go explore/hyper-efficient search engine etc. coming in a sadly distant next/N-th place.

Why do you assume they are using it that way and not ultimately using it "as a tool for gathering context/additional points of research"?

Because they say "is this true" and "is this real," not, "provide context" or "where can I go to learn more", and the answer quality reflects that.

Is this true and is this real is just how people talk. Human conversation isn't so contextually strict as programming language.

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.

Probably same people who discuss war plans on Signal.

Ad populum fallacy will now be replaced by Ad AI said so.... the funny part is the "Sources??" people are some of the most reliant on it

Well I appreciate the attempt to keep the naming somewhere to DVWA...

As a part-time community college educator: I found using "Damn" in course work is problematic in discussions with colleagues or students that felt it might not be appropriate and asked me to change it. DVWA is obviously not my work to change, so I had to clone it and rename it, which is easy enough for me, but not most educators (remember: most cyber security teachers in the USA are high school Math teachers). It can be easy to stick to the acronym in a lot of cases, but it tends to pop out for carious reasons...

In my role supporting coursework for the Commonwealth of Virginia: I'd love to consider adding this to the Virginia Cyber Range / US Cyber Range, but we serve middle schoolers (or younger!) and that's 100% a "bad word". It would make our lives (and anyone in our boat) easier if if was renamed to even "Darn"

Damn, what a great example of freedom of speech country where you cannot even say...words. I cannot believe nor express how childish it looks to me that in the USA you cannot say the N word. I don't even dare to write it here as I don't want to get my account banned. So sad. So much freedom...

> Congress shall make no law ....

Parents are the ones saying "Damn" is inappropriate. Employers don't want to get a frivolous lawsuit. Congress has not limited my speech.

I was just commenting here in case the project owner wanted to increase the potential distribution of their content. Put simply, having "Damn" in the name means that it will face a distribution problem in the under-18 age range.

I personally have no issues with the word, but DVWA has been extremely popular, and I am crossing my fingers for more content, in general, that is like that.

You have had college students come to you and complain that your course material includes a tool with Damn in the title? That's wild. Do you teach in South western part of the state?

Damn, great work. I just added it to https://github.com/Puliczek/awesome-mcp-security to reach more people :)

Imagine using a hammer that can be set to hit your thumb instead of the nail. That's kinda like using MCP.

Accurate.

Reply on news.ycombinator.com