CVE-2025-59333

The mcp-database-server (MCP Server) 1.1.0 and earlier, as distributed via the npm package @executeautomation/database-server, fails to implement adequate security controls to properly enforce a "read-only" mode. This vulnerability affects only the npm distribution; other distributions are not impacted. As a result, the server is susceptible to abuse and attacks on affected database systems such as PostgreSQL, and potentially others that expose elevated functionalities. These attacks may lead to denial of service and other unexpected behaviors.

The mcp-database-server (MCP Server) 1.1.0 and earlier, as distributed via the npm package @executeautomation/database-server, fails to implement adequate security controls to properly enforce a "read-only" mode. This vulnerability affects only the npm distribution; other distributions are not impacted. As a result, the server is susceptible to abuse and attacks on affected database systems such as PostgreSQL, and potentially others that expose elevated functionalities. These attacks may lead to denial of service and other unexpected behaviors.

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

Vulnerable code

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 functions

The 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.

Exploitation

While 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:

1. Stored procedures: SELECT some_function_that_updates_data();
2. Internal database administrative operations: 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:

• Simulate a long-running query, for example: query = "SELECT pg_sleep(5 * 60)"
• Now, from the MCP programmatic interface, execute the following query SELECT pid, usename, state, query FROM pg_stat_activity; to get the PID for the long running query
• Next, use the same MCP interface to then request to run the following query: SELECT pg_terminate_backend(PID); and observe the long running query is now terminated

Similar database side-effects may be found in MySQL or SQLite.

Impact

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.

Recommendation

• Don't…

The mcp-database-server (MCP Server) 1.1.0 and earlier, as distributed via the npm package @executeautomation/database-server, fails to implement adequate security controls to properly enforce a "read-only" mode. This vulnerability affects only the npm distribution; other distributions are not impacted. As a result, the server is susceptible to abuse and attacks on affected database systems such as PostgreSQL, and potentially others that expose elevated functionalities. These attacks may lead to denial of service and other unexpected behaviors.

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

Vulnerable code

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 functions

The 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.

Exploitation

While 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:

1. Stored procedures: SELECT some_function_that_updates_data();
2. Internal database administrative operations: 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:

• Simulate a long-running query, for example: query = "SELECT pg_sleep(5 * 60)"
• Now, from the MCP programmatic interface, execute the following query SELECT pid, usename, state, query FROM pg_stat_activity; to get the PID for the long running query
• Next, use the same MCP interface to then request to run the following query: SELECT pg_terminate_backend(PID); and observe the long running query is now terminated

Similar database side-effects may be found in MySQL or SQLite.

Impact

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.

Recommendation

• Don't…