Live data from Hacker News

From MCP to shell: MCP auth flaws enable RCE in Claude Code, Gemini CLI and more

verialabs.com

21–30 of 45 posts

Re: From MCP to shell: MCP auth flaws enable RCE in Claude Code, Gemini CLI and more

#21

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…

Aside from being offtopic or not I want to add that it is indeed well known https://news.ycombinator.com/item?id=41649832

Re: From MCP to shell: MCP auth flaws enable RCE in Claude Code, Gemini CLI and more

#22

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…

Aside from being offtopic or not I want to add that it is indeed well known https://news.ycombinator.com/item?id=41649832

Thanks! Although thinking of it, while it's not deterministically solvable, I'm sure something like this is what currently being done, e.g, let's say are agreed upon tags to demarcate user generated input, then sanitizing is merely, escaping any injected closing tag, (e.g. ) to </user-provided-input> (and flagging it as an injection attempt)

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

#23

Some 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…

There is confusion.

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

#24

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

LLMs are supposed to be smart. Why can't I point it to API docs and have it call an API?

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

#25
post #17

Some 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

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.

Re: From MCP to shell: MCP auth flaws enable RCE in Claude Code, Gemini CLI and more

#26
post #25
post #17

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

yeah, i was comparing MCP clients to browsers. connecting to an MCP shouldn't leave you vulnerable to RCE on your host.

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

#27
MCP 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 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

#28
I know secure code isn't easy to write, but every line of code I've seen come from AI companies (including the big ones) has looked like an unpaid intern wrote it. "Do you trust AI" is not the right question; it's "Do you trust the engineers building AI products?" So far I don't. It doesn't help that it all feels like a repeat of "move fast, break stuff".

Re: From MCP to shell: MCP auth flaws enable RCE in Claude Code, Gemini CLI and more

#29

MCP 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…

Neither the protocol, nor the technologies it uses, nor the capabilities it exposes are new or even novel.

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.

Post reply on HN