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 but it's not revolutionary. What's revolutionary is everyone training their models for a tool calling spec and I'm just not sure that we've seen that yet.

  > Glad it’s fixed!

Good research. I'm glad people are hopping on this. Lots of surface area to cover and not enough time!

I've disabled all MCP servers on my machine until this security nightmare is fully resolved.

MCP is not that elegant anyway, looks more like a hack and ignores decades of web dev/security best practices.

IT start with "Evil MCP Server".

So you need a server flawed + XSS issue on Cloudflare.

Then you need to use Claude Code, so it's more an issue in Claude Code/Gemini implementation already than MCP.

So if you are ok to run any MCP from any source you have worse issues.

But good find in the open command how it's used in Claude Code/Gemini.

Is $2,300 the going rate for an RCE with a totally believable attack vector these days?

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 duality of input, we use bytes, (and in many cases in the form of a string) to convey both commands and data, "rm -rf /" can be an input in a document about dangerous commands, or a command passed to a shell command executor by a tool call. To mitigate such injection attacks, in most programming language there are ways to clearly separate data from commands, in the most basic way, via deterministic lexical structure (double quotes) or or escaping / sanitizing user input, denly-list of dangerous keywords (e.g. "eval", "javascript:", "__proto__") or dedicated DSLs for building commands that pass user input separately (Stored procedures, HTML builders, shell command builders). The solution to the vulnerability in the post is one of them (sanitizing user input / deny-list)

But even if LLMs will have a fundamental hard separation between "untrusted 3rd party user input" (data) and "instructions by the 1st party user that you should act upon" (commands) because LLMs are expected to analyze the data using the same inference models as interpreting commands, there is no separate handling of "data" input vs "command" input to the best of my understanding, therefore this is a fundamentally an unsolvable problem. We can put guardrails, give MCPs least privilege permissions, but even with that confused deputy attacks can and will happen. Just like a human can be fooled by a fake text from the CEO asking them to help them reset their password as they are locked out before an important presentation to a customer, and there is no single process that can 100% prevent all such phishing attempts, I don't believe there will be a 100% solution to prevent prompt injection attacks (only mitigated to become statistically improbable or computationally hard, which might be good enough)

Is this a well known take and I'm just exposing my ignorance?

EDIT: my apologies if this is a bit off topic, yes, it's not directly related to the XSS attack in the OP post, but I'm past the window of deleting it.

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 behavior when you execute untrusted code.

Also, while I'm generally uncomfortable with being in a position to defend Google, it's a bit questionable calling the Google fix "not very robust" for escaping single quotes in PowerShell.

Perhaps minimal, but this does in fact prevent the specific attack vector they demonstrated. The criticism seems unnecessarily harsh given that Google addressed the vulnerability immediately.