Have you read the article? The source of the attack is an inbound email received in the logged in user's mailbox and read by the logged in user's Claude Desktop app.
Did you? It beggars belief how stupid this is. Yes, if you hook up your Claude client to an email MCP and a shell MCP then it's like you're piping emails to your shell.
The underlying cause can be applied in other contexts. There was recently a flow where this vulnerability was exploited through an IDE working on customer tickets.
Don't dismiss the root cause because the usecase is silly. The moment some user provided input reaches an LLM context, all bets are off. If you're running any local tools that provide shell access, then it's RCE, if you're running a browser / fetch tool that's data exfil, and so on.
The root cause is that LLMs receive both commands and data on the same shared channel. Until (if) this gets fixed, we're gonna see lots and lots of similar attacks.
Have you seen an "official" MCP directly provided by an email service yet?
I had assumed they weren't doing this precisely because of the enormous risk - if you have the ability to both read and send email you have all three legs of the lethal trifecta in one MCP!
So far, I have only seen unofficial MCPs for things like Gmail that work using their existing APIs.
"At Microsoft, we believe in creating tools that empower you to work smarter and more efficiently. That’s why we’re thrilled to announce the first release of Model Context Protocol (MCP) support in Microsoft Copilot Studio. With MCP, you can easily add AI apps and agents into Copilot Studio with just a few clicks."
Does that include an official
Microsoft MCP for access to Outlook or other Microsoft email services??
That second link looks to me like an announcement of MCP client support, which means they get to outsource the really bad decisions to third-party MCP providers and users who select them.