Exposed Local MCP Servers

An exposed local MCP server is one meant for a single person or machine that other people can reach. The usual cause is simple. The server listens on all network interfaces (0.0.0.0) instead of only the local machine (127.0.0.1), and it has no login. Anyone on the same Wi-Fi, office network, or sometimes the internet can then list its tools and use them.

Researchers have found this pattern at scale. Backslash Security reported in June 2025 that the most common issue in its review, "with hundreds of cases observed," was servers "explicitly bound to all network interfaces (0.0.0.0)." It named the problem "NeighborJack."

The MCP specification already says what to do. The Streamable HTTP transport page says local servers SHOULD bind only to localhost and SHOULD authenticate all connections. This page covers the risk and the fixes. Sources were checked on 28 October 2026.

How servers end up exposed

Many server frameworks and tutorials use 0.0.0.0 so a server works inside containers or across machines. Copy that setting to a laptop and the server is open to the whole network.

Some servers ship this way by default. The mysql_mcp_server advisory (CVE-2026-59971) says that in SSE mode "the service binds to 0.0.0.0 by default with no authentication on any route." An attacker could call its execute_sql tool directly. The advisory rated it CVSS 10.0. Version 0.4.2 fixed it and recommends binding to 127.0.0.1.

Developer tools are affected too. Oligo Security showed that the MCP Inspector proxy started on port 6277 with no authentication, which let attackers run commands. The official advisory rated it critical and fixed it in 0.14.1. Oligo also reported finding Inspector instances "exposed to the internet."

What researchers found

Knostic says it only sent "a safe, read-only tools/list request" and never called tools. Backslash says it had covered "about half of what is available" at the time. Both studies are from 2025, so treat them as a snapshot, not a current count.

Backslash also warned about the combination. Some servers were both network-exposed and able to run commands, letting a nearby attacker take control of the host.

An illustrative example

This scenario is illustrative, not a real incident.

A consultant runs a file-management MCP server on their laptop so their AI app can organize client folders. The server listens on 0.0.0.0:3000 with no password, copied from a tutorial.

They work from a coworking space for a day. Another person on the same Wi-Fi scans the network, finds port 3000, and sends a tools/list request. They see read_file and write_file. They read the consultant's client contracts.

Who is at risk

• Anyone running a local MCP server over HTTP or SSE, especially on shared networks such as offices, hotels and coworking spaces.
• Developers using containers, where 0.0.0.0 inside the container may be published to the host network.
• Teams that deploy "internal" servers on cloud machines without authentication, assuming nobody will find them.
• Organizations without an inventory, where these servers are what OWASP calls shadow MCP servers.

How to detect it

• On each machine, list listening ports. On macOS or Linux, lsof -i -P | grep LISTEN works. Look for MCP servers bound to * or 0.0.0.0.
• From another machine on the same network, try reaching that port. If it answers, it is exposed.
• Send an unauthenticated tools/list request to internal servers. A protected server should refuse.
• Use your external attack surface tools to check for MCP endpoints on public IPs.

How to reduce the risk

Server side

The best practices page says servers meant to run locally SHOULD:

1. Use the stdio transport "to limit access to just the MCP client."
2. If using HTTP, restrict access by requiring an authorization token, or by using Unix domain sockets or other restricted IPC.

The transport spec adds binding to 127.0.0.1 and authentication, and makes Origin validation a MUST. That last rule blocks DNS rebinding, which can reach even localhost-bound servers.

Backslash's own advice matches: "Prefer stdio transport for local MCP tools" and, if SSE is required, "restrict access to 127.0.0.1 only."

Client side

• Prefer the stdio version of a server when one exists.
• Treat any config that points at http:// on a LAN address as a warning sign.

Organization side

• Keep an approved list of MCP servers and scan for others. OWASP lists "MCP09:2025 - Shadow MCP Servers" in its MCP Top 10.
• Use host firewalls on staff laptops that block inbound connections by default.
• Run local servers in a sandbox with limited file and network access. See sandboxing local MCP servers.
• Require authentication on any MCP server deployed to a shared or cloud network, even "internal" ones. Our guide to MCP authentication and OAuth covers the options.

What the spec says

The Streamable HTTP spec lists three rules: MUST validate Origin, SHOULD bind to 127.0.0.1 locally, SHOULD authenticate all connections. The authorization spec makes authorization optional overall. That means an unauthenticated server is not a spec violation, which is exactly why exposure is common.

Next step

Run the listening-port check on a few staff machines this week. If you find MCP servers you did not know about, our MCP readiness audit builds a full inventory and fixes exposure. For the full list of threats, visit the MCP Security Center.

Frequently asked questions