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
slyn 55 minutes ago [-]
>Saying MCP is vulnerable is like saying "Web applications are vulnerable”
Just for reference, this GitHub follows in the tradition of many an example project all of which have the explicit intent of demonstrating not that the underlying concept is inherently vulnerable, but that implementations can be.
Damn Vulnerable Web App is probably the best known, but there are others for REST apis, web sockets, GraphQL, and more. They’re educational reference implementations that are deliberately insecure to use as an educational tool.
eddythompson80 39 minutes ago [-]
Except that all the “vulnerabilities” listed are addressed (or can be only addressed) by treating tbr MCP server as a client application.
If a Damn Vulnerable Web App demo was just 10 or 20 different “there no authn/authz on this endpoint”, it would be a crappy demo
kiitos 2 hours ago [-]
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.
BeetleB 2 hours ago [-]
Yes. I've written my own server and feel totally secure in using it, because I have complete control over what it can do (example, I let it send mail, but only to my email address).
If you want it to write to disk, you can put explicit controls on where, and what file size, and whether it can overwrite.
If you want it to read from disk, you can restrict to a simple whitelist that doesn't have confidential/private information.
I have not yet used open source servers out there, because it's a lot of burden for me to limit it to only what I allow.
lolinder 2 hours ago [-]
How did you get started writing your own and hooking it up? Were you just working off the spec, or are there any guides or docs you'd recommend?
mindcrime 1 hours ago [-]
Not the person you asked, but I've gone down this rabbit hole recently and can maybe add something. First, let me say that I don't find much value in the stdio transport stuff and really only care about the http/sse side.
Given that, I found that the docs at modelcontextprotocol.org are somewhat lacking. They seem to assume that you want to use stdio and don't have much meat on setting up sse.
The good news is, the official Python SDK repo has examples of both scenarios. Between the actual "example servers" in the examples/ dir[1], and comments sprinkled around some of the various module files[2][3] themselves, everything you need to write an sse based server/client pair (in Python at least) is there. Note that most of what I just said is true mainly if you want to use the lowlevel / "vanilla" SDK. Using FastMCP makes things a lot simpler and faster.
If you're interested, I keep a repo with some of my experiments and samples as I'm learning this stuff. Feel free to poke around there and see if any of those examples help:
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.
What a weird thread. Who posts an AI prompt as a source of truth
jkingsman 3 hours ago [-]
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.
jsight 2 hours ago [-]
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"?
latchkey 1 hours ago [-]
I did out of curiosity. Remember that Github feeds AI, new developers use AI to generate code, now what is the lowest bar of asking AI "if this code is safe".
gs17 3 hours ago [-]
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.
latchkey 60 minutes ago [-]
This.
daxfohl 51 minutes ago [-]
Probably same people who discuss war plans on Signal.
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"
Mystery-Machine 31 minutes ago [-]
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...
ldoughty 14 minutes ago [-]
> 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.
paulddraper 2 hours ago [-]
Say Darn.
pizzafeelsright 3 hours ago [-]
MCPs remind me of inter personal relationships.
The idea of using them outside a high trust environment seems out of place.
macinjosh 2 hours ago [-]
Imagine using a hammer that can be set to hit your thumb instead of the nail. That's kinda like using MCP.
Rendered at 20:22:14 GMT+0000 (Coordinated Universal Time) with Vercel.
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
Just for reference, this GitHub follows in the tradition of many an example project all of which have the explicit intent of demonstrating not that the underlying concept is inherently vulnerable, but that implementations can be.
Damn Vulnerable Web App is probably the best known, but there are others for REST apis, web sockets, GraphQL, and more. They’re educational reference implementations that are deliberately insecure to use as an educational tool.
If a Damn Vulnerable Web App demo was just 10 or 20 different “there no authn/authz on this endpoint”, it would be a crappy demo
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.
If you want it to write to disk, you can put explicit controls on where, and what file size, and whether it can overwrite.
If you want it to read from disk, you can restrict to a simple whitelist that doesn't have confidential/private information.
I have not yet used open source servers out there, because it's a lot of burden for me to limit it to only what I allow.
Given that, I found that the docs at modelcontextprotocol.org are somewhat lacking. They seem to assume that you want to use stdio and don't have much meat on setting up sse.
The good news is, the official Python SDK repo has examples of both scenarios. Between the actual "example servers" in the examples/ dir[1], and comments sprinkled around some of the various module files[2][3] themselves, everything you need to write an sse based server/client pair (in Python at least) is there. Note that most of what I just said is true mainly if you want to use the lowlevel / "vanilla" SDK. Using FastMCP makes things a lot simpler and faster.
If you're interested, I keep a repo with some of my experiments and samples as I'm learning this stuff. Feel free to poke around there and see if any of those examples help:
https://github.com/mindcrime/MCPSandbox
I've got FastMCP and "vanilla SDK" examples of sse server/client pairs, and a stdio based example mostly cribbed from the "quickstart guide".
My next step is going to be to start working with the Java SDK, so some Java samples will probably show up there soon'ish.
[1]: https://github.com/modelcontextprotocol/python-sdk/tree/main...
[2]: https://github.com/modelcontextprotocol/python-sdk/blob/main...
[3]: https://github.com/modelcontextprotocol/python-sdk/blob/main...
* 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
[0] https://github.com/modelcontextprotocol/servers/issues/866
https://medium.com/@sgt101/trust-me-im-an-agent-78e4bbdb288a
if you trust it, you're fine.
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"
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.
The idea of using them outside a high trust environment seems out of place.