With my limited understanding of LLMs and MCPs (and please correct me if I'm wrong), even without having to exploit an XSS vulnerability as described in the post (sorry for being slightly off topic), I believe MCPs (and any tool calls protocol) suffer from a fundamental issue, a token is a token, hence prompt injection is probably impossible to 100% protect against. The main root cause of any injection attack is the…
From MCP to shell: MCP auth flaws enable RCE in Claude Code, Gemini CLI and more
21–30 of 45 posts
Re: From MCP to shell: MCP auth flaws enable RCE in Claude Code, Gemini CLI and more
#22With my limited understanding of LLMs and MCPs (and please correct me if I'm wrong), even without having to exploit an XSS vulnerability as described in the post (sorry for being slightly off topic), I believe MCPs (and any tool calls protocol) suffer from a fundamental issue, a token is a token, hence prompt injection is probably impossible to 100% protect against. The main root cause of any injection attack is the…
Aside from being offtopic or not I want to add that it is indeed well known https://news.ycombinator.com/item?id=41649832
Then we just need to train LLMs to 1. not treat user provided / tool provided input as instructions (although sometimes this is the magic, e.g. after doing tool call X, do tool call Y, but this is something the MCP authors will need to change, by not just being an API wrapper...)
2. distinguish between a real close tag and an escaped one, although unless it's "hard wired" somewhere in the inference layer, it's only a matter of statistically improbable for an LLM to "fall for it" (I assume some will attempt, e.g. convince the LLM there is instruction from OpenAI corporate to change how these tags are escaped, or that there is a new tag, I'm sure there are ways to bypass it, but it's probably going to make it less of an issue).
I assume this is what currently being done?
Re: From MCP to shell: MCP auth flaws enable RCE in Claude Code, Gemini CLI and more
#23Some of the comments seem to imply that MCP servers should be safe to connect to regardless of trust level, like websites you can safely visit. But MCP servers are more analogous to a PyPI packages you pip install, npm modules you add to your project or a VSCode extension. Nobody would argue that pip is fundamentally broken because running pip install malicious-package can compromise your system. That's expected beha…
1. Not all MCP tools connect to the web or fetch emails. So the shortcut all MCP's are doomed is also the wrong way to adress this.
2. Issue is with MCP with untrusted external sources like web/email that need sanitization like we do with web forms.
3. A lot of warning point bad MCP's! But that apply to any code you might download/ use from the internet. Any package can be flawed. Are you audit them all?
So yeah, on my side I feel this security frenzy over MCP is over hyped. VS the real risk and there is a lot of shortcuts, masking a key issue that is supply chain as an MCP owned issue here and I see that in so many doom comment here.
Re: From MCP to shell: MCP auth flaws enable RCE in Claude Code, Gemini CLI and more
#24Unsurprising. I've left many a comment on what I think of MCP and so have many others. I'm still not sure why everyone's acting like it's some well thought out system and not just tool descriptions shoveled into JSON and then shoved at an LLM. It's not a fundamental architectural change to enhance tool calls, it just got given a fancy name. I do get that having a common structure for tool calling is very convenient b…
And why wouldn't we move toward that direction instead of inventing a new protocol?
Re: From MCP to shell: MCP auth flaws enable RCE in Claude Code, Gemini CLI and more
#25Some of the comments seem to imply that MCP servers should be safe to connect to regardless of trust level, like websites you can safely visit. But MCP servers are more analogous to a PyPI packages you pip install, npm modules you add to your project or a VSCode extension. Nobody would argue that pip is fundamentally broken because running pip install malicious-package can compromise your system. That's expected beha…
i'd honestly say it's closer (but not analogous) to opening a website in your browser. you wouldn't expect javascript on a website to be able to escape the sandbox and run arbitrary code on your computer. companies taking this seriously and awarding bounties is indicative it's fairly severe
So there is a chain of issues and you need to leverage them to get there and first pick an MCP that is flawed from a bad actor.
Re: From MCP to shell: MCP auth flaws enable RCE in Claude Code, Gemini CLI and more
#26Earlier quoted context omitted.
i'd honestly say it's closer (but not analogous) to opening a website in your browser. you wouldn't expect javascript on a website to be able to escape the sandbox and run arbitrary code on your computer. companies taking this seriously and awarding bounties is indicative it's fairly severe
this issue is not even MCP at the core. Claude Code/ Gemini CLI were opening "url's" without sanitization and validation. That's the core flaw. There is a second issue with an XSS flawed package too in the bridge that is easy to patch. So there is a chain of issues and you need to leverage them to get there and first pick an MCP that is flawed from a bad actor.
also, the way MCP servers are presented right now is in sort of a "marketplace" fashion meaning it's not out of the question you could find one hosted by a bad actor. PyPI/npm are also like this, but it's different since it's not like you can vet the source code of a running MCP. packages are also versioned, unlike MCP where whoever is hosting them can change the behaviour at any time without notice.
Re: From MCP to shell: MCP auth flaws enable RCE in Claude Code, Gemini CLI and more
#27MCP is a novel technology that will probably transform our world, provides numerous advantages, comes with some risks, and requires skill to operate effectively.
Sure, none of the underlying technologies (JSON-RPC, etc.) are particularly novel. But the capability negotiation handshake built into the protocol is pretty darn powerful. It's a novel use of existing stuff.
I spent years in & around the domain of middleware and integrations. There's something really special about the promise of universal interoperability MCP offers.
Just like early-aviation, there are going to be tons of risks. But the upside is pretty compelling and worth the risks. You could sit around waiting for the kinks to get worked out or dive in and help figure out those kinks.
In fact, it seems I'm the first person to seriously draw attention to the protocol's lack of timeout coordination, which is a serious problem[0]. I'm just a random person in the ecosystem who got fed up with timeout issues and realized it's up to all of us to fix the problems as we see them. So there's still plenty of opportunity out there to jump in and contribute.
Kudos to this team for responsibly contributing what they found. These risks are inherent in any new technology.
[0]: https://github.com/modelcontextprotocol/modelcontextprotocol...
Re: From MCP to shell: MCP auth flaws enable RCE in Claude Code, Gemini CLI and more
#28Re: From MCP to shell: MCP auth flaws enable RCE in Claude Code, Gemini CLI and more
#29MCP feels like the 1903 Wright Flyer right now. MCP is a novel technology that will probably transform our world, provides numerous advantages, comes with some risks, and requires skill to operate effectively. Sure, none of the underlying technologies (JSON-RPC, etc.) are particularly novel. But the capability negotiation handshake built into the protocol is pretty darn powerful. It's a novel use of existing stuff. I…
What is novel is the "yolo vibe code protocol with complete disregard to any engineering practices, and not even reading at least something about that was there before". That is, it's world's first widely used vibe-coded protocol.
That's why you have one-way protocols awkwardly wrapped to support two-way communication (are they on their third already?). That's why auth is an afterthought. That's why there's no timeout coordination.