MySQL MCP Server: Missing Origin/Host Validation in SSE Transport Enables Unauthenticated SQL Execution (DNS Rebinding / Direct Exposure)

## Summary In SSE/HTTP transport mode, `mysql_mcp_server` constructs `SseServerTransport` without passing `security_settings`. As a result, the MCP Python SDK's DNS-rebinding protection (Origin/Host header validation) is disabled; the Starlette application has no CORS or TrustedHost middleware; and the service binds to `0.0.0.0` by default with no authentication on any route. **Trigger condition:** `MCP_TRANSPORT=sse`. The default stdio mode is not affected. ## Attack Scenarios **Scenario A — Direct exposure:** Any network attacker can invoke `execute_sql` to run arbitrary SQL without credentials → full data dump, and via MySQL `FILE` privileges, arbitrary file read/write and RCE. **Scenario B — DNS rebinding (local bind):** An attacker lures a victim's browser to a malicious page, rebinds their domain to `127.0.0.1`, and uses the browser as a proxy to invoke `execute_sql` as same-origin. ## Root Cause In `src/mysql_mcp_server/server.py`: 1. `SseServerTransport` is constructed without `security_settings` — the SDK defaults `enable_dns_rebinding_protection` to `False`. 2. The Starlette app has no CORS or TrustedHost middleware. 3. All three routes (`/`, `/sse`, `/messages/`) are unauthenticated. 4. The service binds to `0.0.0.0` by default. 5. The sink is `cursor.execute(query)` with a fully attacker-controlled query. ## Impact - Unauthenticated arbitrary SQL execution against the configured database - Full data exfiltration and modification - If the MySQL account holds `FILE`