Can A Website Make Your MySQL MCP Server Run SQL?

September 12, 2026

Yes. A malicious website could use DNS rebinding to invoke SQL through affected MySQL MCP Server SSE deployments before version 0.4.2.

Yes—a malicious website could make an affected MySQL MCP Server run SQL if version 0.4.1 or earlier was running with its SSE transport. The newly reviewed advisory says the server accepted unauthenticated MCP requests without validating the browser's Host or Origin, allowing a DNS-rebinding page to reach a service on localhost. A server exposed directly to the network did not need the browser trick at all.

Watch The 30-Second Summary

Watch this video on YouTube

The fix is available. Version 0.4.2 added DNS-rebinding protection and Host/Origin allowlists, and PyPI now lists 0.4.4 as the current release. The project's default stdio mode was not affected.

This is not evidence that every MySQL MCP installation was compromised. It is a sharp example of why “running locally” is not the same as “reachable only by software you trust.”

Who This Is For

This guide is for developers and operators who:

If you only used the default stdio transport, the advisory says this vulnerability did not affect that path. You should still verify the actual configuration rather than infer it from how your client appears on screen.

What Is Confirmed

GitHub rates the flaw critical

GitHub's reviewed GHSA-rqfv-2mw9-78g2 advisory, assigned CVE-2026-59971, gives the issue a CVSS score of 10.0. The affected package is mysql-mcp-server before 0.4.2 when it runs in SSE mode.

The vulnerable server created its SSE transport without the relevant security settings. It did not validate Host or Origin, did not add a trusted-host or CORS boundary, and did not authenticate the /, /sse, or /messages/ routes. Its documented SSE host default was 0.0.0.0, meaning all available network interfaces rather than loopback alone.

Those conditions exposed the MCP tool layer—not merely a status page. The project's execute_sql tool can run read queries and data-changing statements, including INSERT, UPDATE, and DELETE, subject to the privileges of the configured MySQL account.

There were two attack paths

The maintainer's advisory distinguishes direct network exposure from DNS rebinding.

With direct exposure, an attacker who could reach the SSE port could initialize a session and invoke the SQL tool without credentials. This could happen when an operator published the service to a LAN, VPN, container network, tunnel, or the public internet without a separate authenticated gateway.

With DNS rebinding, the service could still be attacked while listening on the victim's own machine. A malicious website first appears to the browser under an attacker-controlled domain. The site's DNS answer later changes to 127.0.0.1. Because the vulnerable MCP server did not reject the unexpected Host or Origin, the browser could become a same-origin bridge from the remote page to the local SSE service.

The current Model Context Protocol transport specification explicitly warns servers to validate Origin, bind local services to 127.0.0.1 instead of 0.0.0.0, and authenticate connections. It names DNS rebinding as the consequence when those protections are missing.

Ordinary form CSRF was not the browser path

The original public disclosure issue includes an important limiting detail. A normal cross-site HTML form cannot silently send the required JSON request because the content type causes a CORS preflight. The demonstrated browser path relied on DNS rebinding, which changes what address the attacker's own hostname resolves to.

That distinction matters. “Any webpage can immediately POST SQL to localhost” is too broad. The defensible statement is that a hostile website could use DNS rebinding against the unvalidated SSE service.

Version 0.4.2 added the missing boundary

The project's 0.4.2 release, published June 20, enabled the MCP Python SDK's DNS-rebinding protection. It added configurable Host and Origin allowlists, with localhost and 127.0.0.1 defaults, and documented safer remote deployment behind an authenticated reverse proxy.

PyPI's current project page now lists version 0.4.4. Upgrading to a current release is the first response, but it is not the whole response: an intentionally remote SSE service still needs authentication, narrow network exposure, and a least-privileged database identity.

Database privileges determine the blast radius

The advisory says unauthenticated SQL could allow data theft or modification. It also describes file read, file write, and potential code execution when the configured MySQL account has the FILE privilege and the server environment makes those operations useful.

That last branch is conditional. MySQL's own security guidance says not to grant FILE to nonadministrative users because it can let an account read files available to the MySQL operating-system user or create files where that user can write. MySQL also recommends constraining file operations with secure_file_priv.

So the maximum CVSS score describes a reachable worst-case configuration. It does not prove that every affected MCP server could execute operating-system code.

What Is Still Unclear

Whether anyone exploited this in the wild

Neither the reviewed advisory nor the project's disclosure reports a confirmed victim, stolen dataset, altered database, malicious website campaign, or incident-response finding. The researcher says internet-wide scanning identified 25 publicly reachable SSE instances, but a reachable instance is not a compromised instance.

The count is also a point-in-time claim from the disclosure, not a current inventory. It does not establish which versions those systems ran, whether an upstream gateway authenticated them, what data they could reach, or whether they are still online.

How many installations actually used SSE

The project supports both stdio and SSE. Stdio was the default and was not affected. The README recommended SSE for remote or self-hosted use, which makes the vulnerable path operationally plausible, but there is no authoritative count of SSE deployments.

Package downloads, repository stars, and forks do not answer that question. A downloaded package may never run, and one installation may be isolated while another is publicly exposed.

Which database permissions affected deployments used

The MCP service operates with the MySQL credentials its operator provides. A read-only account narrows the consequences to data access. An account with write privileges permits data changes. An administrative account or one with FILE substantially expands the possible impact.

No reviewed source provides a privilege distribution for real deployments. Treat the advisory as a reason to inspect the configured database identity, not as proof that every installation had root-like authority.

Whether your reverse proxy already blocked the attack

Some deployments may have placed the SSE service behind a reverse proxy that authenticated clients, enforced allowed hosts, restricted source networks, or terminated connections before they reached the MCP routes. Those controls could interrupt one or both attack paths.

But their presence cannot be assumed from a diagram or hostname. Verify the effective configuration, including container port mappings, tunnel settings, forwarded headers, firewall rules, and any route that bypasses the proxy.

Use The REBIND Check Before Reopening The Service

Upgrading closes the reported software flaw. A short deployment review helps ensure that the same authority is not still exposed through another route.

R — Release

Confirm the installed package, image, lockfile, and running process are all on 0.4.2 or later. Current PyPI metadata lists 0.4.4.

For a Python environment, a defensive inventory can start with:

python -m pip show mysql-mcp-server

Do not stop at a source repository that contains the patch. Confirm the artifact actually installed in the environment that serves MCP traffic. Rebuild containers and restart the process if the old dependency may still be loaded.

E — Exposure

Map every route to the SSE listener:

If remote SSE is not required, disable it and return to stdio. If it is required, avoid direct public exposure and allow only the clients and networks that need it.

B — Browser Boundary

Keep DNS-rebinding protection enabled. Configure exact allowed hosts and origins for the names you actually serve. Do not treat permissive CORS as authentication, and do not broadly allow arbitrary origins to make a client error disappear.

The fix defaults to localhost-oriented allowlists. Remote deployments need intentional values, especially behind proxies that rewrite or forward Host headers. Test that an unexpected Host and Origin are rejected before declaring the service safe.

I — Identity

Put authentication in front of every network-reachable MCP route. The project's current security documentation says SSE has no built-in authentication and recommends an authenticated reverse proxy for remote use.

Authentication should apply to session creation and message submission, not just a landing page. Rotate any gateway secret that may have been exposed in logs or configuration, and do not embed long-lived service credentials in browser code.

N — Narrow Database Authority

Create a dedicated MySQL account for the MCP server. Grant only the databases, tables, and operations the intended assistant workflow requires. For analysis-only use, prefer SELECT without write or administrative privileges.

Do not use the MySQL root account. Remove FILE unless the workflow has a documented, reviewed need for server-side file operations. Review secure_file_priv, the operating-system identity that runs MySQL, and write access to sensitive directories.

Least privilege will not make an unauthenticated endpoint acceptable. It reduces damage if another layer fails.

D — Detect And Respond

Review proxy access logs, MCP server logs, MySQL audit or general logs where available, network-flow records, and cloud exposure history for the period the vulnerable service was active.

Look for unexpected session creation, unknown source addresses or hosts, unusual SQL, bulk reads, schema discovery, data changes, LOAD_FILE, INTO OUTFILE, and new or unexplained database accounts. Preserve evidence before rotating credentials or rebuilding if you suspect misuse.

Absence of a logged event is not proof of absence when logging was disabled or incomplete. Escalate to incident response when sensitive data, destructive SQL, or privileged file operations may have occurred.

What This Does Not Prove

The advisory does not establish that:

The useful lesson is narrower: a local or self-hosted AI tool becomes a network service when it listens over HTTP, and browsers can reach surprising local destinations unless the server validates where requests came from.

This resembles the browser-to-localhost boundary in the Windows ML CLI vulnerability, while the privilege question resembles the broader lesson in why Ollama is not always local. In each case, “local” describes one part of the architecture, not the complete security boundary.

Where OpenVeil Fits—And Where It Does Not

OpenVeil is relevant when an adult wants a narrower, privacy-focused hosted conversational workspace and does not need to give an AI assistant live database credentials, SQL execution, shell access, public-network reach, or persistent agent authority.

Normal OpenVeil chat history stays in browser storage rather than a normal server-side chat-history record. Active requests are still processed by OpenVeil and necessary providers. OpenVeil is not fully offline or anonymous, and it is not a MySQL MCP patch, reverse proxy, firewall, database-permission manager, DNS-rebinding defense, vulnerability scanner, or incident-response service.

That boundary is the point. If the task is explaining a query, drafting SQL against a synthetic schema, or reasoning about a redacted error, a conversational workspace may be enough. Do not paste live credentials, unredacted customer records, or secrets into any AI service. If the task genuinely requires live database action, secure and audit that tool path as production infrastructure.

You can review OpenVeil's privacy approach or try OpenVeil for work that does not require an agent to operate your database.

Frequently Asked Questions

Is mysql-mcp-server still vulnerable?

The reported flaw affects versions before 0.4.2 in SSE mode. Version 0.4.2 added the fix, and PyPI currently lists 0.4.4. Verify the version actually running, not just the version in a repository or dependency file.

Was stdio mode vulnerable?

The advisory says no. The issue applied when MCP_TRANSPORT=sse was enabled. Stdio communicates through a client-launched subprocess rather than unauthenticated HTTP routes.

Could any website run SQL on localhost?

An attacker-controlled site could use DNS rebinding against the affected SSE service because it lacked Host and Origin validation. Ordinary cross-site form submission was not sufficient for the JSON message path described in the disclosure.

Does binding to 127.0.0.1 fix everything?

No. Loopback binding removes direct network exposure, but DNS rebinding is specifically a browser-to-localhost risk. Use a fixed release with Host/Origin validation as well. A remote deployment also needs authentication and network restrictions.

Does the CVSS 10 score mean attackers got server code execution?

No. The confirmed primitive was unauthenticated SQL execution through the MCP tool. File access and potential code execution require additional conditions, including a MySQL account with FILE and a useful writable location or other unsafe server configuration.

Should I rotate the MySQL password?

If an affected SSE service was reachable by untrusted clients, rotating its dedicated credential is prudent after preserving relevant evidence and closing the exposure. Rotation alone does not remove unauthorized data changes or files, so review logs and database state too.

The Bottom Line

mysql-mcp-server before 0.4.2 could let an unauthenticated network client—or a malicious website using DNS rebinding—invoke SQL through an SSE deployment. The default stdio path was not affected, version 0.4.2 fixed the missing Host/Origin checks, and current PyPI metadata lists 0.4.4.

Upgrade, map the real exposure, enforce exact Host and Origin rules, authenticate remote access, reduce the MySQL account to the minimum privileges, and review evidence from the vulnerable period. Do not turn a claim about a critical reachable configuration into a claim that every local MCP user was compromised.

Sources

Research checked through September 11, 2026.

When privacy, account control, uploads, and search matter, OpenVeil gives you a private AI workspace designed for that job.