| Package | Affected versions | Patched versions |
|---|---|---|
| mcp database server | ≤ 1.1.0 | |
| @executeautomation/database-server | ≤ 1.1.0 |
The MCP Server provided by ExecuteAutomation at https://github.com/executeautomation/mcp-database-server provides an MCP interface for agentic workflows to interact with different kinds of database servers such as PostgreSQL database. However, the mcp-database-server MCP Server distributed via the npm package @executeautomation/database-server fails to implement proper security control that properly enforce a "read-only" mode and as such it is vulnerable to abuse and attacks on the affected database servers such as PostgreSQL (and potentially other db servers that expose elevated functionalities) and which may result in denial of service and other unexpected behavior.
This MCP Server is also publicly published in the npm registry: https://www.npmjs.com/package/@executeautomation/database-server
The vulnerable code to SQL injection takes shape in several ways:
startsWith("SELECT") can include multiple queries because the pg driver for the client.query() supports multi queries if terminated with a ;startsWith("SELECT") can include denial of service queries for stored procedures and other internal db functionsThe tool call here in index.ts is vulnerable:
// Handle tool calls
server.setRequestHandler(CallToolRequestSchema, async (request) => {
switch (request.params.name) {
case "read_query": {
const query = request.params.arguments?.query as string;
if (!query.trim().toLowerCase().startsWith("select")) {
throw new Error("Only SELECT queries are allowed with read_query");
}
try {
const result = await dbAll(query);
return {
content: [{ type: "text", text: JSON.stringify(result, null, 2) }],
isError: false,
};
} catch (error: any) {
throw new Error(`SQL Error: ${error.message}`);
}
}
The MCP Server exposes the tool read_query with a naive attempt to guard for exclusive "read-only" mode that allows only data retrieval from the server by performing a check on the provided query string to ensure that it starts with a "SELECT" query.
In short, the code check startWith("select") is not an adequate security control to strict for read-only mode queries and can be abused for side-effects and database-level operations.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeWhile allowing only SELECT type queries might seem like a good defense to allow only data retrieval and not data manipulation in any way (hence, "read-only" mode), it is a non-suficient way of protecting against database servers that expose extra functionality through internal function calls.
Several examples that will allow side effects through SELECT queries:
SELECT some_function_that_updates_data();SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE ...;Even when the database is known not to have any stored procedures defined, an attacker can still cause significant availability and service disruption by executing pg_terminate_backend().
Following is a reproduction:
query = "SELECT pg_sleep(5 * 60)"SELECT pid, usename, state, query FROM pg_stat_activity; to get the PID for the long running querySELECT pg_terminate_backend(PID); and observe the long running query is now terminatedSimilar database side-effects may be found in MySQL or SQLite.
The above exploitation surfaces two significant security risks: a denial of service that affects availability and confidentiality dislcosure that allows users unauthorized access to queries running on the server and potential leak of data.
SELECTSELECT * ...; INSERT INTO ...Recommended CWE: CWE-284: Improper Access Control Recommendec CVSS: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:H
Disclosed by Liran Tal