I’ve been building a simple MCP server in Rust to expose some internal tooling, and I’ve run into a behavior I can’t quite explain. My server is configured to only listen on `127.0.0.1:3000`, and I'm using the `sse` transport. I’ve verified with `netstat` and `lsof` that it's bound correctly and not exposed to the network.
However, I’m seeing log entries indicating incoming requests originating from `localhost:8080`. These are not coming from my client (which I have running on a known, separate port). The requests are malformed—they don't conform to the MCP protocol structure I’ve implemented—and are causing a bunch of parse errors and warnings in my logs.
Here’s a sanitized snippet of the log output:
```
2025-01-15T14:33:22.481Z WARN [my_mcp_server::transport] Received non-SSE GET request on /sse endpoint. Origin: http://localhost:8080
2025-01-15T14:33:22.482Z ERROR [my_mcp_server::protocol] Failed to parse initial client payload: unexpected end of input at line 1 column 0
```
My immediate thoughts and what I've checked so far:
* **Binding:** The server is explicitly bound to `127.0.0.1:3000`. No wildcard `0.0.0.0`.
* **Firewall:** `ufw` is active, but shouldn't matter for localhost traffic.
* **Other Processes:** I don't have another service running on port 8080 that I'm aware of. `ss -tulpn | grep :8080` returns nothing.
* **Client Configuration:** My actual MCP client (a separate Rust binary) is configured to connect to `ws://127.0.0.1:3000/sse`. It doesn't use port 8080 for anything.
This raises a bunch of security and isolation questions for me:
1. **Provenance:** How can I definitively trace what process on my system is making these requests to `127.0.0.1:3000` from a source port `8080`? Tools like `ss` or `lsof` show the connection to my server, but not the initiating process for these ephemeral requests.
2. **MCP-Specific:** Is there any known behavior in common MCP clients or servers (like the `@modelcontextprotocol` libraries) that might spawn secondary, internal HTTP clients on different ports? Could this be some form of health-check or discovery probe I'm unaware of?
3. **Sandbox Escape Vector:** If this *is* an unknown local process, it highlights a bigger issue: MCP servers often perform powerful local operations (file I/O, shell commands). If another local application can blindly connect to my MCP server's SSE endpoint, what's stopping it from sending a well-formed, malicious `tools/call` request? My server uses the `sse` transport, which, as I understand it, lacks any inherent authentication—it seems to rely entirely on network boundary security (i.e., "it's on localhost, so it's trusted").
My current hypothesis is that some other locally installed tool (maybe a VS Code extension, a backgrounded dev server, or a previously installed agent runtime) is periodically probing ports. But I need to be sure.
Has anyone else observed stray traffic to their MCP servers? More importantly, what are the recommended patterns for authenticating requests at the MCP protocol level, rather than relying solely on the loopback interface? Should I be implementing a shared secret in the `Authorization` header, even for local development?
trace -e all
Check your local dev tools. It's likely a browser tab open on port 8080 with a stale React/Vite dev server making automatic health checks or hot reload pings. Your SSE endpoint is probably catching stray HTTP traffic.
Add a strict path filter or a required header for the SSE route to reject these. Don't just rely on the binding.
--lin
That sounds frustrating. I'm new to MCP and still figuring things out, but I've run into stray localhost requests too. What confused me at first is that binding to 127.0.0.1 only controls where your server listens, not what can reach it. Anything on your own machine can still send requests to that port.
user463's suggestion about a dev server is probably right. Could you check if you have any other local services running? Sometimes I forget about old docker containers or background processes. The log says it's a GET request to /sse - is that your exact endpoint path, or could a generic health check be hitting it?
You've already validated the binding, which is good. Now you need to validate the origin. `netstat` won't help with that.
The log line `Origin: http://localhost:8080` is your smoking gun. That's a browser CORS header. This is almost certainly a frontend dev server (like Vite or webpack) running on 8080, and its auto-reload or health-check logic is hitting any open local port it can find.
Do this: run `curl -I http://localhost:8080` and see what responds. Then add a mandatory `Accept: text/event-stream` header check to your `/sse` endpoint. Reject anything else with a 400. That will filter out the junk HTTP traffic.
trust, but verify — with sigtrap