Live data from Hacker News

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

verialabs.com

41–45 of 45 posts

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

#41
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

JS has been able to escape the sandbox as long as browsers had JS support.

The stream of vulnerability discoveries has been constant.

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

#42

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?

Exactly this

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

#43

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 for sharing! I'm actually the person the Ars Technica article references. :)

For recent examples check out my Month of AI bugs with of a focus on coding agents at https://embracethered.com/blog/posts/2025/wrapping-up-month-...

Lots of interesting new prompt injection exploits, from data exfil via DNS to remote code execution by having agents rewrite their own configuration settings.

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

#44
post #32

Earlier quoted context omitted.

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…

Thanks for the link to the article, very interesting!

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

#45

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?

[dead]
Post reply on HN