[Security] DNS rebinding protection disabled by default — all default MCP servers vulnerable

[hhhashexe]

Security Issue: Insecure Default Configuration

File: src/mcp/server/transport_security.py lines 40–41

Issue: TransportSecurityMiddleware disables DNS rebinding protection by default:

# If not specified, disable DNS rebinding protection by default for backwards compatibility
self.settings = settings or TransportSecuritySettings(enable_dns_rebinding_protection=False)

Developers following official examples and tutorials do not pass security_settings — they deploy without DNS rebinding protection.

Impact

An attacker on the same network (coffee shop Wi-Fi, corporate network) can:

1. Serve a malicious webpage with DNS rebinding payload
2. Connect attacker JS to victim's local MCP server (bypasses same-origin)
3. Invoke any registered MCP tool — file reads, shell commands, API calls

Recommended Fix

Change the default to secure-by-default:

def __init__(self, settings: TransportSecuritySettings | None = None):
 # Secure by default
 self.settings = settings or TransportSecuritySettings(enable_dns_rebinding_protection=True)

Provide explicit opt-out for backwards compatibility.

---

Reported by @hhhashexe · SkillFence Security

[pcarleton]

Thanks for the report. This was addressed in v1.23.0 (Dec 2025) — see commit d3a1841.

The middleware fallback at transport_security.py:41 is intentionally permissive for backwards compat, but it's not reached in default configurations. Both sse_app() (mcpserver/server.py:919-925) and streamable_http_app() (lowlevel/server.py:529-535) auto-enable DNS rebinding protection when host is 127.0.0.1, localhost, or ::1 and no explicit transport_security is provided.

Since the default host is 127.0.0.1, servers following official examples are protected.

The fallback only applies if you construct transport primitives directly without going through MCPServer — at which point you've opted into manual configuration.

Closing as already fixed.

For future reports: if you believe you've found an exploitable vulnerability, please use GitHub's private vulnerability reporting rather than a public issue. It lets us assess and coordinate a fix in private. Public issues are fine for hardening suggestions or defense-in-depth ideas that aren't directly exploitable.