Every MCP database server enforces read-only with a string check -- and it's bypassable

From Theory Delta | Methodology | Published 2026-02-24

What the docs say

MCP database servers advertise a "read-only mode" that restricts agents to SELECT queries, preventing data modification. The official Anthropic MCP SQLite reference server and community implementations all offer this as a safety feature for connecting agents to production databases.

What actually happens

Every MCP database server reviewed implements read-only enforcement as a string prefix check. None use SQL AST parsing. Here is the actual code:

executeautomation/mcp-database-server (source, security advisory GHSA-65hm-pwj5-73pw):

// index.ts:272-291
if (!query.trim().toLowerCase().startsWith("select")) {
  throw new Error("Only SELECT queries are allowed with read_query");
}

modelcontextprotocol/servers mcp-server-sqlite (issue #3314):

# mcp_server_sqlite/server.py:326
results = db._execute_query(
    f"PRAGMA table_info({arguments['table_name']})"
)

The table_name parameter is interpolated directly into the PRAGMA statement without sanitization. Input like users); DROP TABLE users; -- executes arbitrary SQL. The reference implementation that builders copy from has an open SQL injection.

This means:

• False rejections: CTEs (WITH ... AS (...) SELECT ...) are blocked because they start with WITH, not SELECT. Legitimate read-only queries fail silently.
• False acceptances: PostgreSQL writable CTEs (WITH deleted AS (DELETE FROM ...) SELECT ...) start with WITH but mutate data. If the guard allows WITH to fix the above, it opens a write path.
• MySQL SELECT INTO OUTFILE passes the prefix check in haxzie/sequel-mcp -- confirmed, not theoretical. Starts with SELECT, writes to the filesystem.
• Multi-query chaining: SELECT 1; DROP TABLE users passes the prefix check because only the first statement is inspected. The pg driver supports multi-query execution when statements are semicolon-terminated.

The NL2SQL correctness ceiling compounds the problem: SOTA on enterprise schemas (Spider 2.0) is ~17% for o1-preview, ~10% for GPT-4o. Spider 1.0's commonly cited 86.6% uses toy schemas and is a misleading baseline.

What to do instead

1. Add a SQL AST parser (sqlglot for Python, node-sql-parser for Node) that identifies statement type before execution. String prefix checks are not a security boundary.
2. Use parameterized queries -- neither executeautomation nor haxzie/sequel-mcp separates parameters from query strings. Parameterized queries eliminate the SQL injection class entirely.
3. Sandbox any code execution path -- if your NL2SQL stack generates visualization code or transformation scripts, run them in a subprocess with restricted imports or a container with no network access. Input filtering will not stop LLM role-switching attacks.
4. Do not trust the Anthropic reference server as a secure starting point. Issue #3314 is open. Audit describe_table and any PRAGMA-using path before deploying.
5. Test schema discovery tools against your actual database -- MySQL 8.0 RDS returns 748 null entries from list_tables in executeautomation (issue #23, open). Agents silently fall back to raw information_schema queries, bypassing the tool abstraction.

Environments tested

Confidence and gaps

Confidence: empirical -- source code reviewed and vulnerability confirmed across 3 MCP database servers, benchmarks reviewed across 4 additional tools. Security advisory GHSA-65hm-pwj5-73pw independently confirms the finding.

Open questions: Does any MCP database server implement AST-based read-only enforcement? Are there production deployments using parameterized queries through MCP tool calls? Has anyone shipped a sandboxed execution path for NL2SQL visualization code?

Seen different? Contribute your evidence -- theory delta is what makes this knowledge base work.