Let’s talk about MCPs. You’ve probably heard of them, and maybe you’ve read the security risks associated with them. Sure, they sound worrying, but when you put them into a real-world context, they can quickly become far more concerning than you can ever imagine.

Just last week, our system flagged a suspicious Chrome extension. It sent messages to a port on localhost — nothing too odd at first glance, but as we dug deeper, we found that this extension communicated with an MCP server running on the local machine.

The fact that Chrome extensions can communicate with MCPs is a serious risk. The consequences are enormous. The usual security measures like Chrome’s sandbox model, don’t stand a chance.

You’re looking at unauthenticated access to the filesystem and, in some cases, a full machine takeover. That’s not just a small issue; that’s a massive, game-changing vulnerability.

And here’s the kicker: any Chrome extension can exploit this. No special permissions required. If there’s a vulnerable MCP server running on a host machine, that’s it. We’ve already found vulnerable MCP servers tied to services like filesystem access, Slack, WhatsApp, and more. This isn’t just a theoretical risk anymore, it’s real, and the impact could be devastating.

So, if you’re running MCP locally, it’s time to seriously reevaluate your security. We were mindblown when we found this, and it’s time everyone else takes notice before it’s too late.

So, buckle up and get ready, let’s dive into this together.

A Suspicious localhost connection

While monitoring browser extension activity, our detection engine flagged a Chrome extension making network requests to localhost. Although the extension itself showed no signs of malicious behavior, the destination caught our attention. It was communicating with a local service implementing the Model Context Protocol (MCP) — a protocol used to interface AI agents with system tools and resources on the endpoint.

This raised an immediate concern: if a browser extension can talk to an MCP server running on the user’s machine, what’s stopping it from accessing sensitive resources or executing privileged actions through the MCP?

MCP: Open by Default

Let’s first understand how MCP clients communicate with MCP servers. There are 2 standard transport implementations -

1. Server-Sent Events (SSE) — enables the MCP server to communicate through HTTP POST requests.
2. Standard Input/Output (stdio) — enables the MCP server to communicate through the process’s standard input and output streams.

When implementing an MCP server, the developer can choose how the MCP server will communicate. The server can support both transport methods.

It’s important to note that the transport layers themselves do not implement, or require, any authentication mechanism. It is up to the MCP server developer to implement access controls, but in practice, nearly all MCP servers today do not enforce authentication by default.

For local use, an MCP server that relies on Server-Sent Events (SSE) typically binds to a port on localhost, making it accessible from processes running on the same machine (like an MCP client).

Sandbox, Meet Sledgehammer

Now that we understand how a local SSE-based MCP server operates, and that it’s generally accessible to processes running on the same machine, we can revisit the question: can a Chrome extension access it as well?

The communication flow is fairly straightforward:

• The client sends a GET request to the server to obtain a session ID and a messages endpoint — without any form of authentication.
• Once initialized, the client can issue POST requests to that message’s endpoint to retrieve the list of available tools exposed by the MCP server and invoke them directly.

First we set up a local SSE-based MCP server from mcp.so, specifically choosing a file-system variant, which allows AI clients to interact with the local file system. Following the setup instructions in the server’s README:

node dist/index.js ~/work/mcp/private_directory

Next we built a Chrome extension that runs in the background and attempts to connect to localhost:3001 - a commonly used port for local SSE-based MCP servers. Of course, this port may vary, so a real-world extension would need to scan local ports to locate the active MCP instance. The extension gets the server information, retrieves the tools list and tries to invoke the tools provided by the MCP server:

The Chrome extension had unrestricted access to the MCP server’s tools — no authentication needed — and was interacting with the file system as if it were a core part of the server’s exposed capabilities. The potential impact of this is massive, opening the door for malicious exploitation and complete system compromise.

Integrating with a different MCP server required virtually no effort, thanks to the protocol’s design goal: providing a unified interface for interacting with various MCP servers, regardless of their underlying implementation.

We’ve also tried setting up a Slack MCP, our Chrome extension was able to access it and interact with its exposed functionality:

This POC demonstrates a complete sandbox escape in Chrome’s extension architecture. While Chrome has tightened security controls around private network access, browser extensions remain a notable exception.

In 2023, Google introduced stricter measures to prevent websites from reaching into users’ private networks (e.g., localhost, 192.168.x.x, etc.) — a move aimed at protecting internal infrastructure from being probed or attacked via malicious scripts running on public websites.

September 2023: Chrome 117 rolls out to Stable, ending the deprecation trial. Chrome blocks all private network requests from public, non-secure contexts.

Although Chrome extensions operate with elevated capabilities compared to regular web pages, they are still designed to adhere to Chrome’s sandboxing principles — remaining isolated from the operating system and local resources unless explicitly granted permission.

However, unrestricted access to localhost breaks that isolation barrier, enabling unexpected interaction with both the local machine and the broader organizational environment — especially through exposed services like local MCP servers.

Contain the Chaos

Since its introduction, the MCP ecosystem has expanded rapidly, with thousands of servers offering diverse capabilities. While this brings powerful new possibilities, it also introduces a growing set of security risks. As demonstrated, a simple Chrome extension, without any special permissions, can breach the sandbox, connect to a local MCP server, and execute privileged actions on behalf of the user. This effectively shatters the isolation model that browser sandboxes were built to uphold. And when these MCP servers expose access to tools like the filesystem, Slack, or WhatsApp without enforcing authentication, the stakes skyrocket from a theoretical concern to an enterprise-wide threat.

For security teams, this is not just a new vector, it’s an entirely new attack surface, and one that is dangerously underestimated. MCPs are already being deployed in developer environments and production systems, often with minimal oversight or access controls. If left unchecked, they provide an open backdoor into endpoints, bypassing traditional defenses. Governing MCP usage, enforcing strict access policies, and closely monitoring extension behavior must become non-negotiable priorities.