When DNS rebinding is combined with Server-Sent Events, an attacker can keep a live connection open while the browser believes it is talking to a trusted public domain. That lets the attacker pivot traffic toward localhost and interact with an internal MCP server. If CORS or preflight behavior is misconfigured, the attacker may also read streamed responses and forward sensitive content off the host.
Why This Matters for Security Teams
DNS rebinding plus Server-Sent Events is dangerous because it turns a browser into a long-lived relay between an attacker-controlled origin and an internal MCP endpoint. In an MCP environment, that matters even more because tool access often reaches credentials, local services, or internal systems that were never meant to be exposed through a browser session. The browser may believe it is streaming from a trusted public domain while the underlying network path shifts to localhost after the DNS change.
This pattern is especially risky in agentic environments, where an mcp server may be wired into workflow automation, code execution, or data retrieval. Current guidance from the OWASP Agentic AI Top 10 treats insecure tool exposure and over-broad connectivity as core risks, and NHIMG research on The State of MCP Server Security 2025 shows how often MCP deployments still leave secrets and permissions too loose for this threat model. In practice, many security teams discover this only after a local service has already been queried through a browser-originated tunnel.
How It Works in Practice
The attack usually starts with a page that opens an SSE connection to a domain the browser initially resolves as public. If the application accepts cross-origin streaming requests too loosely, the attacker can keep that connection open while forcing a later DNS resolution to point at localhost or another internal IP. SSE is useful to the attacker because it is persistent, low-friction, and designed for streaming updates rather than one-off request checks.
In MCP environments, that persistence can let the attacker interact with a server that was assumed to be local-only or protected by “same network” trust. The danger increases when the MCP server exposes unauthenticated tool endpoints, weak CORS rules, or preflight handling that does not correctly validate origin and intent. When the browser becomes the transport layer, the attacker may not need direct network reachability at all.
- Enforce strict origin validation on every SSE handshake and every follow-on request.
- Reject wildcard CORS policies for any endpoint that can reach MCP tools or local services.
- Bind sensitive MCP listeners to loopback with additional authentication, not loopback alone.
- Use per-request authorization for tools, not assumptions based on the browser session.
OWASP’s OWASP Top 10 for Agentic Applications 2026 is useful here because it frames tool abuse and trust boundary failure as runtime security problems, not just configuration mistakes, and NHIMG’s Analysis of Claude Code Security shows how quickly local automation surfaces can become security boundaries. These controls tend to break down when an MCP server is exposed through a browser-accessible helper app that relies on CORS instead of real server-side authentication.
Common Variations and Edge Cases
Tighter SSE and CORS controls often increase implementation overhead, forcing organisations to balance browser compatibility against the need to keep internal MCP services unreachable by rebinding tricks. That tradeoff becomes sharper when teams want local developer convenience, because “it only runs on localhost” is not a security control if the browser can still be persuaded to talk there through a rebinding sequence.
There is no universal standard for this yet, but current guidance suggests treating SSE endpoints as high-risk whenever they can reach privileged tooling or secret-bearing services. The edge cases are usually operational: proxy layers that rewrite headers, development builds that relax origin checks, or MCP gateways that trust the client too much. If an SSE stream can carry tool output back to the browser, the same path can also leak sensitive responses unless the server enforces strict authorization on each event source.
This is why browser-facing MCP integrations should be reviewed like remote code execution surfaces, not simple web APIs. The safest pattern is to minimize browser-to-tool directness, prefer server-mediated calls with explicit auth, and assume any long-lived stream can be turned into an exfiltration channel. The failure mode is most common in developer workstations and internal test environments where localhost is trusted by convention, because that is exactly where DNS rebinding attacks are easiest to miss.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10, CSA MAESTRO and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A04 | Covers tool abuse and boundary failures in agent-connected browser flows. |
| CSA MAESTRO | T1 | Addresses agent tooling trust boundaries and unsafe connectivity to internal services. |
| NIST AI RMF | Supports governing runtime AI-system risk and operational misuse scenarios. | |
| OWASP Non-Human Identity Top 10 | NHI-01 | Relevant because MCP endpoints often expose secrets through weakly protected identities. |
| NIST CSF 2.0 | PR.AC-3 | Network access control is central to preventing browser pivot into localhost services. |
Document the rebinding threat as an operational AI risk and assign monitoring and response ownership.
