Improper Access Control vulnerability in Mastra AI template project template-text-to-sql

The Mastra AI template template-text-to-sql described A Mastra workflow system for database introspection and natural language to SQL conversion. Features PostgreSQL schema analysis, AI-powered query generation, safe SQL execution, and interactive workflows for database operations.

Resources:

• Project's GitHub code repository: https://github.com/mastra-ai/template-text-to-sql

Overview

The AI agent code at https://github.com/mastra-ai/template-text-to-sql/blob/main/src/mastra/tools/sql-execution-tool.ts#L41 provides a tool for agentic workflows to interact with a PostgreSQL database. However, the template-text-to-sql AI agent project fails to implemented proper security control that truly enforce a "read-only" mode and as such it is vulnerable to abuse and attacks on the PostgreSQL database server that can result in denial of service and other unexpected behavior.

Vulnerability

The sqlExecutionTool tool made available to the agent 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.

export const sqlExecutionTool = createTool({
  id: 'sql-execution',
  inputSchema: z.object({
    connectionString: z.string().describe('PostgreSQL connection string'),
    query: z.string().describe('SQL query to execute'),
  }),
  description: 'Executes SQL queries against a PostgreSQL database',
  execute: async ({ context: { connectionString, query } }) => {
    const client = createDatabaseConnection(connectionString);

    try {
      console.log('🔌 Connecting to PostgreSQL for query execution...');
      await client.connect();
      console.log('✅ Connected to PostgreSQL for query execution');

      const trimmedQuery = query.trim().toLowerCase();
      if (!trimmedQuery.startsWith('select')) {
        throw new Error('Only SELECT queries are allowed for security reasons');
      }

      const result = await executeQuery(client, query);

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 AI agent interaction 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 AI agent interface to then request to run the following query: SELECT pg_terminate_backend(PID); and observe the long running query is now terminated

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 rely solely on the "starts with" SELECT.
• Remove the Secure / Safe language from the README and instead require developers to address proper security controls for querying.
• The database server to use fine-grained permissions for users on the database server with strict and explicit access to specific capabilities on the server.

CVE Details

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

References and Prior work

1. GitHub Kanban MCP Server found vulnerable to command injection.
2. iOS Simulator MCP Server found vulnerable to command injection.
3. Liran's Node.js Secure Coding for educational materials on injection attacks and secure coding practices.
4. https://www.nodejs-security.com/blog/how-to-bypass-access-control-in-postgresql-in-simple-psql-mcp-server-for-sql-injection
5. Reference example from prior security research on this topic, demonstrating how vulnerable MCP Server connected to Cursor is abused with prompt injection to bypass the developer's intended logic:

Credit

Disclosed by Liran Tal