by telotortium on 5/1/25, 2:01 PM
Literally nothing here is specific to MCP - it all has to do with the fact that Chrome extensions can make HTTP connections to localhost ports, which could be running any kind of server. This is not an unrestricted backdoor either - Chrome extensions already need permissions in the manifest to talk to localhost, except via content scripts, which run in the context of the website and so could be served by the website without any extension installed.
by fluffet on 5/1/25, 1:54 PM
Woah, I had no idea. Thanks for the article.
I feel like some cycle phenomenon has been reached here..
The first protocols of the internet were very naive. Why'd you need to encrypt traffic? What do you mean exploit DNS, why would anyone do that?
Then people realised that the internet is a really, really wild place and that won't do.
I suddenly feel old, because this new AI tool era seems to have forgotten that lesson.
I feel it's like watching crypto learn by any% speedrunning why regulations and oversight might be a good in the first place (FTX and such).
I hope the next generation of AI tech/protocols are more robust, trust just doesn't cut it, or we'll see plenty of fingers being burnt at the stove.
by npace12 on 5/1/25, 12:50 PM
by bhelx on 5/1/25, 4:09 PM
This is the first i've heard of people using the SSE transport locally. What purpose what that serve? Is this by design because the chrome extension could not talk to it otherwise?
BTW, you should really run your MCP servers in a sandboxed environment, esp if they don't need to do things like `exec` or read from the filesystem. We do this with the https://mcp.run ecosystem by wrapping them in wasm. Because they are wasm you could also run them right in the chrome extension!
by OsrsNeedsf2P on 5/1/25, 2:07 PM
Lots of people think MCP is a case of "wow, how did we forget basic security", but I wonder if there were other competitors that MCP beat _because_ they had security friction.
by skybrian on 5/2/25, 1:44 AM
I guess the security hole is that “allow connecting to localhost” might sound like an innocuous permission, but it becomes increasingly risky as you run more servers on local ports that have no other protection.
The permission itself doesn’t tell you anything about what powers it might grant. You need to know how all your local processes work to determine that, and most people have no idea.
It’s too generic for users to make reasonable decisions about. And that means that servers on localhost really should have authentication. Connecting client A to server B should be explicit.
by vovkasm on 5/3/25, 11:00 AM
There is nothing specific to MCP here. But that doesn’t mean there’s no problem. The real problem is that OS does not contain a convenient for users and reliable access control mechanism for local TCP connections (at least at the per-application level of granularity).
Would such a mechanism existed, the user could allow connections to its MCP only to the necessary applications.
There is already many apps providing local servers, all of them is potential point of attack for bad actors in system: ollama, syncthing, adb, gradle, various torrent clients with web interface, media players, etc...
by happyopossum on 5/1/25, 11:25 PM
This isn’t an MCP issue though - if you were running a webserver, or any application that listens on localhost that happens to have vulnerabilities, an extension could hit those too.
Literally nothing about MCP makes this easier or worse
by fpoling on 5/1/25, 9:32 PM
Any service running on local should reject HTTP requests with Origin header as those are generated from browser JS API. In addition requests with UserAgent should also be typically be rejected.
by babyshake on 5/1/25, 8:39 PM
Is it correct that this exploit would not be possible with streamable HTTP MCP servers? I'd imagine that fairly soon every MCP server that does not need filesystem access will use this transport method unless there is some reason why STDIO/SSE would be needed instead. Can anyone confirm if this is the case and if they agree or disagree with this assessment?
by brap on 5/1/25, 3:14 PM
I still don’t understand why we even need a new protocol when we already have something like the OpenAPI spec, which can also be used to describe common authentication mechanisms like OAuth2. And it supports almost every existing API out of the box.
Granted it doesn’t separate between “resources”, “tools” and “prompts” but I think the line is blurry anyway.
And yes it can be used locally.
by ramoz on 5/2/25, 4:25 PM
The cyber industry is having a ball exposing standard security practice issues under the guise of “new zero day AI vulnerabilities” - esp with MCP.
Nothing here is new. If you run local apps with open connections and no CORS then anything on your device and potentially network can talk to that app.
by olalonde on 5/1/25, 5:41 PM
So do we add authentication to MCP servers or does Chrome fix this by restricting unauthorized calls to localhost?
by OsrsNeedsf2P on 5/1/25, 2:01 PM
by rvz on 5/1/25, 2:33 PM
Every time a startup uses an MCP server in their product software offering or even offers their own, I can only see the number of security consultants waiting for a massive payout when an LLM causes a security incident.
by _pdp_ on 5/1/25, 7:43 PM
Also, credentials scattered in clear text inside the MCP configuration. They forgot how to do security!
by ttoinou on 5/2/25, 7:45 AM
Sooo we just need a new standard MCPS (MCP Secure connections), right ?
by gitroom on 5/1/25, 6:12 PM
bruh this stuff honestly makes my head spin - feels like were all relearning the same old security lessons