A maximum-severity flaw in mysql_mcp_server, a widely referenced Model Context Protocol (MCP) server that lets LLM agents query MySQL databases, allows any network attacker — no credentials, no session, nothing — to execute arbitrary SQL against the connected database. Tracked as CVE-2026-59971, the bug carries a CVSS score of 10.0 and was published September 15, 2026.

What happened

mysql_mcp_server (package designcomputer/mysql_mcp_server on PyPI) ships two transport modes: stdio, the default for local single-user setups, and SSE/HTTP, used when the server is deployed as a shared endpoint that multiple agents or clients connect to over the network. The SSE path is where everything goes wrong.

When started with MCP_TRANSPORT=sse, the server constructs its SseServerTransport without passing security_settings or enabling DNS-rebinding protection. That protection exists specifically to make the MCP Python SDK validate incoming Origin/Host headers — without it, the check is simply off. Compounding that, the underlying Starlette application adds no CORS middleware and no TrustedHostMiddleware of its own, and the service binds to 0.0.0.0 by default rather than localhost. The result is three independent layers — SDK-level rebinding protection, application-level host validation, and network-level exposure — all failing open at once.

The practical effect: the execute_sql MCP tool is reachable by anyone who can route a packet to the port, or, if the deployment is actually bound to localhost with a firewall in front of it, by anyone who can get a victim’s browser to load an attacker-controlled page. DNS rebinding lets that page’s JavaScript alternate DNS answers between an attacker server and 127.0.0.1, satisfying same-origin checks and then issuing same-origin requests straight into the local MCP endpoint.

Technical details

The vulnerable code path is server.py’s SSE handler, which passes attacker-controlled input directly into cursor.execute(query) with no authentication middleware anywhere in the request chain. There’s no API key, no bearer token, no mTLS requirement — just an open HTTP endpoint accepting SQL. Affected versions are everything prior to 0.4.2; the stdio transport, which most local single-agent setups use, is not affected because it never exposes a network listener.

This is the same failure pattern showing up repeatedly across the MCP ecosystem this year: projects built for a single trusted local user get a network transport bolted on for multi-tenant or remote-agent use cases, and the authentication layer that should gate that transport never gets built. NVIDIA’s NemoClaw hit the identical DNS-rebinding-into-unauthenticated-API pattern against Ollama in August; Nginx UI’s /mcp_message endpoint shipped with IP allowlisting but no auth check back in April. CVE-2026-59971 is the same architectural gap, this time sitting directly on top of a production database.

Impact

Any organization running mysql_mcp_server in SSE mode — whether to let multiple internal agents share one database connector, or as part of a larger agentic pipeline — is exposing full read/write access to whatever MySQL account the server authenticates as. That’s a complete data dump at minimum. If the configured MySQL account has FILE privilege, the same unauthenticated access chains into arbitrary file read/write on the database host via LOAD_FILE()/INTO OUTFILE, and from there into remote code execution in common MySQL deployment configurations.

Because MCP servers are typically wired directly into an organization’s most sensitive data sources — the entire point is giving an LLM agent structured access to a database — the blast radius here isn’t a side service. It’s whatever the agent was trusted to see and touch, with no requirement that the attacker know anything about the environment beyond the SSE endpoint’s address.

Mitigation

  • Upgrade to mysql_mcp_server 0.4.2 or later immediately. The fix restores DNS-rebinding protection and enables proper host/origin validation on the SSE transport.
  • Audit your MCP deployment topology. If you’re running any MCP server in SSE/HTTP mode, confirm it’s bound to localhost or an internal-only interface, not 0.0.0.0, and sits behind an authenticating reverse proxy — don’t rely on the MCP server’s own transport layer for access control.
  • Prefer stdio transport for single-agent, single-host deployments where a network listener isn’t actually needed; it removes this entire attack class.
  • Check MySQL account privileges used by any MCP connector — an account with FILE privilege turns a SQL-injection-class bug into RCE, so scope credentials down to only what the agent workflow requires.
  • Review access logs for execute_sql calls or SSE connections from unexpected source IPs if you’ve been running an affected version exposed to any untrusted network segment, including your internal LAN.

No CISA KEV listing or confirmed in-the-wild exploitation had been reported at publication time, but a CVSS 10.0 unauthenticated-RCE-adjacent flaw in an AI-agent-facing database connector is exactly the profile scanners pick up within days of disclosure.

Sources: GitLab Advisory Database, OSV.dev — GHSA-rqfv-2mw9-78g2, Strix.ai CVE Analysis