CVE-2026-48774: ProxySQL Multi-Statement SQL Injection in MCP Read-Only Tool

Technical summary

The vulnerability exists in ProxySQL's `run_sql_readonly` MCP tool, which is supposed to enforce read-only semantics for MySQL targets. The implementation performs input validation on the full SQL string using a first-keyword allowlist (accepts queries starting with SELECT) and a substring blacklist for dangerous keywords. However, when the SQL is sent to the backend MySQL connection, it is executed with the `CLIENT_MULTI_STATEMENTS` flag enabled. This allows multiple SQL statements separated by semicolons to execute in a single request. An attacker can bypass the validator by submitting a payload like `SELECT 1; RENAME TABLE old TO new`, which passes validation because it starts with SELECT, but the RENAME TABLE statement executes successfully because it is not caught by the blacklist. Administrative statements such as SET, RESET, LOCK TABLES, and KILL are similarly not rejected. Testing confirmed that the `/mcp/query` endpoint accepted a `run_sql_readonly` request with a side-effecting statement, and backend verification showed the table modification persisted.

Business impact

For organizations using ProxySQL as a database proxy with MCP enabled, this vulnerability enables lateral privilege escalation and database integrity compromise. An attacker with network access to the MCP endpoint can rename, lock, or corrupt critical tables; modify database user accounts and privileges via SET commands; or execute administrative operations that disrupt availability. The damage is constrained by the MCP target account's database privileges, but in many deployments that account will have broad write access. Data integrity violations, unplanned downtime, and forensic challenges to detect unauthorized administrative actions are likely outcomes. Organizations relying on MCP for application or AI tool integration face immediate risk.

Affected systems

ProxySQL versions 3.0.0 through 3.0.8 are vulnerable. The vulnerability only affects deployments with the MCP (Model Context Protocol) feature enabled and the `/mcp/query` endpoint exposed. Version 3.0.9 and later contain the fix. Organizations using ProxySQL for standard MySQL/PostgreSQL proxying without MCP enabled are not at risk. The threat surface depends on network exposure of the MCP listener and authentication controls.

Exploitability

Exploitability is high. No authentication is required if the MCP endpoint is exposed without an auth token (the default configuration). Even with `mcp-query_endpoint_auth` configured, an attacker who obtains or guesses the token can craft the attack without specialized tools or knowledge. The payload is simple: a valid SELECT statement followed by a semicolon and a write or administrative command. No interaction, user action, or special conditions are needed once the attacker reaches the endpoint. The attack succeeds remotely over the network. This is a network-accessible vulnerability with low complexity that requires no privileges or user interaction.

Remediation

Upgrade ProxySQL to version 3.0.9 or later immediately. If an immediate upgrade is not feasible, implement the following interim mitigations: (1) Disable the MCP feature entirely unless it is actively required; (2) Set a strong, non-empty `mcp-query_endpoint_auth` token in the configuration and use a secrets management system; (3) Restrict network access to the MCP listener to trusted application servers only, using firewall rules or network segmentation; (4) Configure the MCP backend target credentials as database-level read-only users to limit the impact of successful exploitation; (5) Implement temporary MCP query rules that block multi-statement patterns (queries containing semicolons or UNION operators) as a detection and prevention layer. Test mitigations in a non-production environment first.

Patch guidance

ProxySQL version 3.0.9 fixes the validation logic to properly reject multi-statement requests at the validation layer before they reach the backend. Verify the specific patch version against the vendor advisory to confirm the fix is present. Test the upgrade in a staging environment to ensure compatibility with your deployment. The upgrade should be low-risk for standard proxy operations, but validate that application-dependent features continue to function as expected. Consider scheduling the upgrade during a maintenance window to minimize impact, although the vulnerability itself creates urgent pressure to patch.

Detection guidance

Monitor MCP query logs for requests containing semicolons or multiple SQL statements, particularly those that combine a SELECT prefix with administrative keywords like RENAME, SET, RESET, LOCK, KILL, ALTER, DROP, CREATE, INSERT, UPDATE, DELETE, or TRUNCATE. Check for unexpected schema changes (table renames, drops, or modifications) that occur shortly after MCP access logs show activity. Enable SQL query auditing on the backend MySQL server to log all executed statements and correlate them with MCP endpoint access. Look for requests to the `/mcp/query` endpoint from unexpected source IP addresses or at unusual times. If MCP auth tokens are configured, audit failed and successful authentication attempts. Review database user privilege logs for unauthorized administrative operations.

Why prioritize this

This is a HIGH severity vulnerability (CVSS 7.5) that violates a core security contract and affects data integrity directly. The combination of network accessibility, no required authentication in default configurations, and the ability to execute privileged database operations makes this critical for any organization with MCP enabled. Even though the attack requires network access to a specific endpoint, that endpoint may be exposed in cloud or multi-tenant environments. The simplicity of the attack—concatenating a valid query with a destructive statement—means it requires minimal sophistication. Prioritize patching or mitigation for all ProxySQL 3.0.x deployments with MCP enabled.

Risk score, explained

CVSS 3.1 score of 7.5 (HIGH) reflects: Attack Vector=Network (any remote attacker can target the endpoint); Attack Complexity=Low (no special conditions required); Privileges Required=None (no authentication needed by default); User Interaction=None (attack is fully automated); Scope=Unchanged (impact is limited to the database itself); Confidentiality=None (no data is disclosed, though integrity is violated); Integrity=High (backend data can be modified, deleted, or corrupted); Availability=None (though RENAME/LOCK operations may impact availability as a side effect). The score does not account for severity mitigations (network segmentation, auth tokens, read-only database users), which operators should apply immediately.

Frequently asked questions