MCP’s Database Problem Is Not Prompt Injection. It Is Old Bugs Wearing an Agent Badge

MCP’s Database Problem Is Not Prompt Injection. It Is Old Bugs Wearing an Agent Badge

The mistake is calling this an MCP security story. It is really a database security story with an agent-shaped blast radius.

Akamai researcher Tomer Peled found serious flaws in MCP servers connected to Apache Doris, Apache Pinot, and Alibaba RDS. The Register’s coverage is fresh, but the vulnerabilities themselves are painfully familiar: SQL injection, missing authentication, weak query validation, unauthenticated metadata exposure. Nothing about those bug classes required a frontier model. They are old web-app failures. The new problem is where they now sit: between an autonomous coding agent and production-ish data.

Akamai says it examined roughly 300 official MCP servers, looking at authentication, authorization, tool capabilities, and back-end invocation paths. The affected projects were not toy examples. Akamai cited Apache Doris at about 15,000 stars, Apache Pinot at about 6,000, and Alibaba RDS as a cloud database integration. That matters because MCP is moving fastest precisely where integrations are useful: data stores, internal tools, observability systems, and workflow APIs.

The bug classes are boring. The deployment pattern is not.

Apache Doris MCP v0.6 and earlier were affected by CVE-2025-66335, a SQL injection issue now fixed in Doris MCP 0.6.1 and later. NVD describes the flaw as improper neutralization in query-context handling that could allow unintended SQL execution and bypass validation or access restrictions through the MCP query execution interface. Akamai’s detail is more concrete: the exec_query path took parameters including query, db_name, catalog_name, max_rows, and timeouts; db_name was not validated or sanitized before being prepended into the final SQL string. The validator checked only the first parsed statement, leaving room for attacker-controlled follow-on SQL.

StarTree’s Apache Pinot MCP integration before v2.0.0 could bind HTTP transport to 0.0.0.0:8080. Anyone able to reach the endpoint could invoke exposed tools, including direct SQL execution. Akamai says StarTree added OAuth as an authentication option, lowering severity, while the SQL-injection risk remains in the code path. Alibaba RDS MCP’s RAG component uses FastMCP on 0.0.0.0:8006 and exposes a get_table_struct tool performing vector similarity search over a table-structure index; Akamai says an unauthenticated client could query table names, schema definitions, and other sensitive metadata. Alibaba reportedly decided not to patch.

Read that again without the “AI” label. An unauthenticated network service exposes schema metadata. A SQL tool binds beyond localhost. A query validator concatenates context into SQL. These are not novel problems. The novelty is that teams are standing them up as agent connectors, often with less review than a normal API endpoint would receive because the integration feels like developer tooling rather than application infrastructure.

Prompt-injection defenses will not save a bad server

The industry has spent a lot of energy worrying about MCP prompt injection, and it should. Tool descriptions can be poisoned. Repo instructions can steer agents. Malicious content can try to manipulate a model into calling the wrong capability. But this disclosure is a useful corrective: even perfect instruction hierarchy does not fix a server that trusts inputs and network reachability too much.

You can teach the model never to run destructive queries and still lose if db_name becomes SQL syntax. You can sandbox the agent’s file system and still leak schema metadata if a RAG endpoint listens unauthenticated on all interfaces. You can add user confirmations and still expose a direct query tool to anyone on the network. The exploit path is not necessarily “the model was tricked.” Sometimes it is “the server was a normal vulnerable service, and the agent gave it a convenient reason to exist.”

That distinction matters for practitioners because it changes the mitigation plan. You do not secure MCP only by adding better prompts. You secure MCP by treating every server as an API gateway with delegated authority. It needs transport authentication, per-tool authorization, strict parameter validation, least-privilege back-end credentials, bounded result sets, audit logs, and a deployment posture that assumes somebody will eventually reach the port you thought was private.

The operational checklist is not optional

If your team runs MCP database servers, start with inventory. Find every .mcp.json, plugin-declared server, local FastMCP experiment, Remote Control connector, and CI agent configuration that can touch a data store. Then classify each server by authority: can it read schemas, execute arbitrary SQL, mutate rows, access credentials, or cross tenant/project boundaries?

Next, enforce boring controls. Upgrade Doris MCP to 0.6.1 or later. Do not expose HTTP/SSE MCP endpoints beyond localhost unless they enforce authentication. Require OAuth or equivalent for remote transports. Validate all parameters server-side, including context fields that look harmless. Use read-only database accounts by default, with separate privileged tools for write paths. Cap result sizes and execution time. Log tool invocations with caller, session, server, database, query shape, and result size. Alert on schema enumeration and unusual query volume. Review container and firewall rules so 0.0.0.0 does not mean “available to the office VPN, CI subnet, and someone’s forgotten test host.”

For Claude Code users, this also intersects with connector visibility. If an agent can discover and call MCP tools from project context, admins need a clear inventory and accurate auth states. A server that fails as “broken” when it is actually “unauthenticated” wastes debugging time and encourages unsafe workarounds. A malformed config that hides other servers undermines review. The control plane has to be legible before it can be governed.

The editorial take: MCP’s database problem is not that agents invented new vulnerability classes. It is that agents are making old classes newly consequential. SQL injection and unauthenticated metadata endpoints were already bad. Put them behind an autonomous workflow with production credentials nearby, and “just glue code” becomes part of the attack surface. The right response is not MCP panic. It is to stop treating agent connectors as exempt from the security practices we already know how to apply.

Sources: The Register, Akamai security research, NVD CVE-2025-66335, OWASP GenAI MCP server guide