MySQL MCP server left SQL wide open in SSE mode

A popular Model Context Protocol connector for MySQL databases allowed unauthenticated attackers to run arbitrary SQL when it was started in its network transport mode, according to a GitHub security advisory published on 11 September 2026.

The flaw, tracked as CVE-2026-59971, affects the pip package mysql-mcp-server. MCP servers act as tool providers for AI agents, and this one exposes an execute_sql tool that runs queries against a configured database. The advisory says that when the server is started with the environment variable MCP_TRANSPORT=sse — a mode that serves the agent over HTTP rather than a local pipe — it builds its SSE transport without passing any security_settings.

That single omission had several consequences. The MCP Python SDK defaults its DNS-rebinding protection, which validates the Origin and Host headers of incoming requests, to off unless it is explicitly enabled. The advisory adds that the underlying Starlette web application carried no CORS or TrustedHost middleware, that all three routes it exposes — /, /sse and /messages/ — were unauthenticated, and that the service bound to 0.0.0.0 by default, meaning it listened on every network interface. The final link in the chain is the tool itself, which passes a fully attacker-controlled query straight to cursor.execute.

The advisory describes two attack paths. In the first, any attacker who can reach the port simply calls execute_sql and runs whatever SQL they like without credentials, allowing a full dump or modification of the database. If the MySQL account used by the server holds the FILE privilege, the advisory says an attacker could also read arbitrary files with LOAD_FILE and write them with INTO OUTFILE, raising the possibility of remote code execution by dropping a webshell.

The second path does not require the server to be exposed at all. Because the Origin and Host checks were disabled, an attacker could lure a victim to a malicious web page, rebind their domain to 127.0.0.1, and use the victim's own browser as a proxy to reach a server bound only to localhost. Requests would arrive looking like same-origin traffic.

The default stdio transport, in which the server communicates over standard input and output with a local client, is not affected. Only the SSE mode triggers the issue.

Internet-wide scanning identified 25 publicly reachable SSE instances of the project, according to the advisory.

A fix has been released in version 0.4.2. The maintainers now pass TransportSecuritySettings(enable_dns_rebinding_protection=True) when constructing the SSE transport, and the documentation recommends binding to 127.0.0.1 rather than all interfaces.

The advisory credits the discovery to three researchers, two of them at Johns Hopkins University.

The case is a plain example of a pattern that recurs across MCP deployments: a component designed for local, single-user use is switched to a network transport, and the security defaults that would normally be supplied by a web framework are simply absent. Operators running any MCP server over HTTP should check whether authentication, host validation and the bind address have been set deliberately rather than inherited.