Disclosure: this page contains affiliate links. East Bay Cyber may earn a commission if you buy through them, at no extra cost to you. That never changes how we rank products. Editorial policy.
CVE-2026-59971: MySQL MCP Server SQL Flaw
Critical CVSS (10.0) reachable over network.
TL;DR - CVE-2026-59971 affects MySQL MCP Server versions before 0.4.2 when SSE transport is enabled. - An unauthenticated network attacker may execute SQL and potentially access server files, depending on database privileges. - Upgrade to 0.4.2 or later, restrict exposure, and review database and host activity immediately.
Vulnerability at a Glance
| Field | Details |
|---|---|
| CVE ID | CVE-2026-59971 |
| CVSS score | 10.0 Critical |
| CVSS vector | Not supplied in the available NVD response; confirm the exact vector in the NVD record |
| Attack vector | Network-based access to the SSE service; DNS rebinding may also relay browser requests to a local service |
| Authentication required | None for the affected SSE routes, according to the vulnerability description |
| Affected versions | MySQL MCP Server versions prior to 0.4.2 |
| Affected configuration | MCP_TRANSPORT=sse |
| Patch status | Yes. Fixed in version 0.4.2 |
| Default stdio transport | Not affected according to the NVD description |
| CISA KEV status | Not listed as of 2026-09-15 |
CVE-2026-59971 is a critical vulnerability in the designcomputer/mysql_mcp_server project. Its practical impact depends on whether the SSE service is reachable and on the privileges assigned to the configured MySQL account.
The highest-risk deployments are those running a pre-0.4.2 version with MCP_TRANSPORT=sse, listening on 0.0.0.0, and accessible from untrusted networks. Internet exposure is not required for serious impact: an attacker with network reachability may be able to read or modify database data without credentials.
For background on vulnerability terminology, see this guide to what a vulnerability assessment is.
What Is This Vulnerability?
The root cause is a combination of missing security controls in the SSE implementation. Before version 0.4.2, the server constructs SseServerTransport without security_settings or enable_dns_rebinding_protection. The routes /, /sse, and /messages/ also lack authentication. The service binds to all interfaces by default through 0.0.0.0, increasing the chance that an unintended network peer can reach it.
The request path ultimately permits attacker-supplied input to reach cursor.execute(query). This creates an unauthenticated SQL execution interface rather than a narrowly scoped, authenticated database operation. An attacker may read or alter database contents and execute SQL available to the configured account. If that account has the MySQL FILE privilege, the impact may extend to reading or writing server files. Further code execution is possible in some environments, but it depends on database permissions, filesystem permissions, server configuration, and the deployed operating system.
The default stdio transport is not affected according to the NVD description. The vulnerability therefore requires administrators to distinguish between installations that use local process communication and those explicitly configured to expose the SSE transport.
Who Is Affected?
Affected software is MySQL MCP Server from the designcomputer/mysql_mcp_server GitHub project, specifically all versions prior to 0.4.2 when SSE transport is enabled. The fixed version is 0.4.2. The available record does not identify separate operating-system or distribution-specific version ranges.
Potentially exposed instances include deployments configured with:
MCP_TRANSPORT=sse
Risk is higher when the service listens on all interfaces:
0.0.0.0
and when firewalls, reverse proxies, or service-mesh policies do not restrict access to trusted clients. Deployments using the default stdio transport are described as unaffected. Administrators should still verify the actual runtime configuration rather than assuming that a package version or deployment template uses stdio.
The database account also determines the blast radius. A minimally privileged account may limit data access, while an account with broad schema permissions can enable extensive disclosure or modification. The FILE privilege is especially important because it can expand the impact from database operations to server-file access.
CVSS Score Breakdown
The NVD-assigned CVSS base score is 10.0 Critical. The available NVD response supplies the score and vulnerability description but does not supply the exact CVSS vector string. Consequently, the precise component values should be confirmed directly in the NVD record before being used for compliance reporting or automated scoring.
The operational characteristics clearly support a severe assessment: the affected interface is reachable over a network, authentication is absent on the relevant SSE routes, and successful exploitation can provide database read and write capability. The potential for file access or code execution further increases consequences when the MySQL account and host permissions allow it.
Because the vector is not available in the supplied record, defenders should not infer unreported details such as exact scope, user interaction, or impact-component values. Use the published 10.0 base score for prioritization, but retrieve the authoritative vector from the NVD entry for CVE-2026-59971 when precise metric breakdown is required.
Exploitation Status
CVE-2026-59971 is not currently listed in the CISA Known Exploited Vulnerabilities catalog. There is therefore no CISA confirmation that the vulnerability is being exploited in the wild, and no CISA due date or ransomware-campaign designation applies.
No verified standalone public proof-of-concept repository or public working exploit was identified in the reviewed sources. GitHub issue #92 and the associated security advisory may contain issue-specific technical information, but the available material does not independently confirm a working exploit. Based on the supplied research, in-the-wild exploitation is not confirmed.
The absence of a KEV entry or verified PoC does not make exposed instances safe. The vulnerable path is described as unauthenticated, and exploitation could be straightforward for an attacker who can reach the service. Organizations should prioritize exposed or broadly reachable SSE deployments without waiting for public exploit code.
How to Detect It
Start by identifying every MySQL MCP Server process and its transport configuration. Search deployment manifests, environment files, systemd units, container definitions, and process arguments for MCP_TRANSPORT=sse. Also determine whether the process is listening on all interfaces and whether a reverse proxy or firewall limits access.
A practical host-level check can include:
ps auxww | grep -i '[m]ysql.*mcp\|[m]cp.*mysql'
ss -ltnp
grep -RIn --exclude-dir=.git 'MCP_TRANSPORT' /etc /opt /srv 2>/dev/null
The exact process name and installation path vary, so these commands are discovery aids rather than definitive signatures. Confirm the installed application version through the package, container image, release metadata, or project checkout. Any version earlier than 0.4.2 using SSE should be treated as vulnerable until upgraded or disabled.
Review HTTP access logs for requests to the affected routes:
"GET /sse
"POST /messages/
"GET /
Look for requests from unexpected source addresses, requests with no authenticated identity, unusual request volume, and activity outside the expected MCP client population. These patterns are indicators, not proof of exploitation, because legitimate MCP traffic may use the same routes.
Database-side telemetry is particularly valuable. Search MySQL audit logs, general query logs, proxy logs, or database activity-monitoring platforms for unexpected statements issued by the MCP service account, including broad SELECT operations, INSERT, UPDATE, DELETE, CREATE, DROP, LOAD_FILE, and INTO OUTFILE activity. For example, a SIEM search conceptually equivalent to the following can identify suspicious statements:
service="mysql" AND user="<mcp-account>" AND
(sql matches "(?i)\b(LOAD_FILE|INTO\s+OUTFILE|UPDATE|DELETE|DROP|CREATE)\b")
Adapt the field names and query syntax to the deployed SIEM. Also review database connection sources, file integrity events, and web or application logs for activity temporally correlated with requests to /sse or /messages/.
Mitigation and Patching
Upgrade MySQL MCP Server to version 0.4.2 or later. The project’s fixed release is available at the v0.4.2 release page, and the NVD references the corresponding fix commit. Use the installation method appropriate to the deployment; for a source checkout, the operational sequence may resemble:
git fetch --tags origin
git checkout v0.4.2
# Reinstall dependencies using the project's documented installation method
# Restart the MySQL MCP Server service
Do not copy this sequence blindly into a package-managed or containerized environment. Pin the deployment to a release that is at least 0.4.2, rebuild the image if required, restart the service, and verify the running version after deployment.
If immediate upgrading is not possible, disable SSE and revert to the default stdio transport where operationally feasible. Remove or unset the SSE configuration, then restart the service:
unset MCP_TRANSPORT
# Restart the service using the applicable service manager
sudo systemctl restart mysql-mcp-server
The service name may differ, and unsetting the variable is appropriate only when the project’s deployment defaults to stdio. Validate that no network listener remains after the change:
ss -ltnp | grep -E '(:[0-9]+).*python|mcp'
For deployments that must continue using SSE, place the service behind network controls that permit only known MCP clients. A bastion host or similarly restricted access point can help reduce exposure; see this overview of what a bastion host is. Do not expose the service directly to the public internet or untrusted internal segments.
Enable authentication and DNS-rebinding protections supported by the fixed implementation and deployment architecture, and verify those controls with an authenticated-client test and an unauthorized-request test.
Finally, reduce the MySQL account to the minimum required privileges. Remove FILE unless it is explicitly needed, restrict access to required schemas and tables, rotate credentials if unauthorized access is suspected, and review database and host logs for historical activity. A password manager such as Try 1Password → can help teams generate and securely manage replacement service credentials during remediation. Network restriction and privilege reduction are defense-in-depth measures; they do not replace upgrading to 0.4.2 or later.
Incident Response Considerations
If logs indicate possible exploitation, preserve relevant HTTP, database, host, container, and reverse-proxy logs before restarting or rebuilding the affected service. Record the vulnerable version, transport configuration, listening interfaces, source addresses, executed SQL statements, and affected database objects.
Temporarily isolate the SSE service from untrusted networks, disable the affected deployment where feasible, and rotate credentials for the MCP database account. Review whether the account had FILE, administrative, or other elevated privileges. Check for unexpected files, modified application code, new processes, persistence mechanisms, and outbound connections on the host.
If sensitive data may have been accessed or changed, follow the organization’s breach assessment and notification procedures. Continue monitoring after patching because attackers may retain access through altered credentials, scheduled tasks, or other persistence mechanisms.
References
The authoritative vulnerability record is the NVD entry for CVE-2026-59971. It contains the published 10.0 CVSS score and the technical description of the affected SSE implementation. The exact CVSS vector should be confirmed there because it was not included in the supplied NVD response.
Project-specific references include the fixed commit, GitHub issue #92, the v0.4.2 release, and the GitHub security advisory.
For exploitation-status validation, consult the CISA Known Exploited Vulnerabilities catalog. As of 2026-09-15, CVE-2026-59971 is not listed there. That status should be rechecked during incident response and patch triage because catalog membership and public reporting can change.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.