Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

verialabs.com

Post reply on HN
Print view View original

31–40 of 45 posts

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

#31

Post by esseph »

mehdibl wrote: post #23
Jimmc414 wrote: post #13

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

This is a blanket statement, just an anecdote from my career.

Every developer I have ever met that wasn't in the security space underestimates security problems. Every one.

YMMV

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

#32

Post by brap »

eranation wrote: post #22
mattigames wrote: post #21

Earlier quoted context omitted.

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

The problem is that once you load a tool’s response into context, there’s no telling what the LLM will do. You can escape it all you want, but maybe it contains the right magic words you haven’t thought of.

The solution is to not load it into context at all. I’ve seen a proposal for something like this but I can’t find it (I think from Google?). The idea is (if I remember it correctly) to spawn another dedicated (and isolated) LLM that would be in charge of the specific response. The main LLM would ask it questions and the answers would be returned as variables that it may then pass around (but it can’t see the content of those variables).

Edit: found it. https://arxiv.org/abs/2503.18813

Then there’s another problem: how do you make sure the LLM doesn’t leak anything sensitive via its tools (not just the payload, but the commands themselves can encode information)? I think it’s less of a threat if you solve the first problem, but still… I didn’t see a practical solution for this yet.

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

#33

Post by electric_muse »

troupo wrote: post #29
electric_muse wrote: post #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…

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

Agreed. I think most can agree that the protocol itself leaves a lot to be desired.

But the idea itself is compelling: documentation + invocation in a bi-directional protocol. And enough real players have thrown their weight behind making this thing work that it probably some day will.

I don't understand fully the "it's immature so it's worthy or ridicule" rationale so much. Don't most good things start out really rough around the edges? Why does MCP get so much disdain?

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

#34

Post by mehdibl »

esseph wrote: post #31
mehdibl wrote: post #23

Earlier quoted context omitted.

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

This is a blanket statement, just an anecdote from my career. Every developer I have ever met that wasn't in the security space underestimates security problems. Every one. YMMV

I'm in the security space so? And been deep in this MCP thingy.

Did you check where I pointed the root issues?

All I'm trying to say there is shortcuts, and confusing over the hype buzz too that is on going in AI, as MCP took off, I so a lot of of papers with IF IF IF condition to point security issues in MCP, while most of the them expect you to pick random stuff at the start. This is why I'm saying "Supply chain" is not MCP. As you can't blame MCP for issue coming from random code you pick. MCP is a transport protocol, you can do similar without MCP but you have to bake your tools inside the AI app, thus loosing the plug & play ability.

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

#35

Post by esseph »

mehdibl wrote: post #34
esseph wrote: post #31

Earlier quoted context omitted.

This is a blanket statement, just an anecdote from my career. Every developer I have ever met that wasn't in the security space underestimates security problems. Every one. YMMV

I'm in the security space so? And been deep in this MCP thingy. Did you check where I pointed the root issues? All I'm trying to say there is shortcuts, and confusing over the hype buzz too that is on going in AI, as MCP took off, I so a lot of of papers with IF IF IF condition to point security issues in MCP, while most of the them expect you to pick random stuff at the start. This is why I'm saying "Supply chain" i…

Ultimately to use Agentic AI, you have to put faith in the model, the training data, the chain of custody, the authentication, the network discovery and connectivity between components, the other tools themselves that get called, and their chain of custody, etc.

It's a massive liability.

Maybe future history will prove me wrong.

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

#36

Post by [deleted] »

troupo wrote: post #29
electric_muse wrote: post #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…

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

[deleted]

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

#37

Post by amannm »

fennecbutt wrote: post #2

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…

MCP doesn't make any sense to exist at this point in time. All you need is CLIs and existing service interfaces. We don't need a new protocol for something whose purpose is to make more protocols unnecessary

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

#38

Post by blcknight »

electric_muse wrote: post #33
troupo wrote: post #29

Earlier quoted context omitted.

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

Agreed. I think most can agree that the protocol itself leaves a lot to be desired. But the idea itself is compelling: documentation + invocation in a bi-directional protocol. And enough real players have thrown their weight behind making this thing work that it probably some day will. I don't understand fully the "it's immature so it's worthy or ridicule" rationale so much. Don't most good things start out really ro…

The problem is the roll out as the bees knees by anthropic, when its.. just some JSON slop without a ton of careful thought behind it.

I think it should be mostly thrown away and start over with an MCPv2 that has first class auth, RBAC/identity, error handling, quotas, human-in-the-loop controls, and more.

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

#39

Post by datadrivenangel »

mehdibl wrote: post #34
esseph wrote: post #31

Earlier quoted context omitted.

This is a blanket statement, just an anecdote from my career. Every developer I have ever met that wasn't in the security space underestimates security problems. Every one. YMMV

I'm in the security space so? And been deep in this MCP thingy. Did you check where I pointed the root issues? All I'm trying to say there is shortcuts, and confusing over the hype buzz too that is on going in AI, as MCP took off, I so a lot of of papers with IF IF IF condition to point security issues in MCP, while most of the them expect you to pick random stuff at the start. This is why I'm saying "Supply chain" i…

You are correct that it is possible to use MCP securely. Like if you build a custom client, and only use trusted third party servers one at a time.

But the hype-promise of "AI" is that you can make the commercial off the shelf ClaudeGPT client magically discover MCP servers and automate everything. And if the majority of people's expectations require vulnerability, you're going to have a bad time.

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

#40

Post by datadrivenangel »

jdns wrote: post #17
Jimmc414 wrote: post #13

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

Malware from untrusted websites is as old as the internet. With advertisements, even trusted sites can deliver hostile content.

The RCE/Malware issue aside, if the website you go to is a login page for some service, do you know it's the legitimate website? MCP Phishing is going to be a thing

Post reply on HN