The Model Context Protocol (MCP) Server provided by Xata, available at xataio/agent, is designed to facilitate agentic workflows with various database servers, including PostgreSQL. However, I identified a critical security flaw in the server’s implementation, which fails to enforce a true “read-only” mode.

This vulnerability exposes the server to SQL injection attacks, potentially leading to denial of service and unauthorized data manipulation. This article explores the vulnerability, its exploitation, and recommended mitigations.

Disclaimer: The flawed code was responsibly disclosed to the Xata team through the GitHub Security Advisory reporting mechanism upon which the maintainers decided to remove the flawed MCP server code entirely from the repository.

Impact & Affected Versions

The vulnerability arises from the assumption that the client.query() method in the PostgreSQL interface only executes a single query. In reality, the pg package allows multiple queries to be executed if separated by semicolons. This oversight can be exploited to bypass the intended “read-only” mode, allowing attackers to execute unauthorized write operations or cause service disruptions.

Affected Code

The vulnerable code is located in the mcp-postgres.ts file of the Xata repository:

// Handle tool calls
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name === 'query') {
    const sql = request.params.arguments?.sql as string;
    const client = await pool.connect();
    try {
      await client.query('BEGIN TRANSACTION READ ONLY');
      const result = await client.query(sql);
      return {
        content: [{ type: 'text', text: JSON.stringify(result.rows, null, 2) }],
        isError: false
      };
    } finally {
      client.release();
    }
  }
});

Technical Root Cause

The vulnerability stems from the naive implementation of a “read-only” transaction, which is easily bypassed by injecting additional SQL commands. For instance, an attacker can terminate the read-only transaction and execute a write operation:

COMMIT; INSERT INTO users (name, email) VALUES ('Eve', 'eve@gibson.com');

This injection effectively bypasses the read-only constraint, allowing unauthorized data manipulation.

Exploitation

Proof of Concept

Consider the following scenarios demonstrating the vulnerability:

1. Bypassing Read-Only Mode:

   • A legitimate query:

     SELECT id, name, email FROM users WHERE id > 5 ORDER BY id;

   • An injected query that bypasses read-only mode:

     COMMIT; INSERT INTO users (name, email) VALUES ('Eve', 'eve@gibson.com');

2. Denial of Service:

   • An injected query causing a denial of service:

     COMMIT; SET statement_timeout TO 1;

Additional Security Impacts

Even without stored procedures, attackers can exploit the MCP interface to perform administrative operations, such as terminating backend processes:

• Retrieve process IDs:

  SELECT pid, usename, state, query FROM pg_stat_activity;

• Terminate a process:

  SELECT pg_terminate_backend(PID);

Mitigation/Upgrade

To mitigate this vulnerability, consider the following recommendations:

• Single Query Transactions: Ensure transactions are only effective when a single query is passed.
• Strict Query Validation: Avoid relying solely on queries starting with SELECT. Implement strict validation to prevent multiple queries.
• Access Control: Enforce fine-grained permissions on the database server, restricting access to specific tables and operations.
• Query Chaining Prevention: Disallow chaining of multiple SQL queries in a single request.

FAQ

What is the primary cause of this SQL read-only bypass?

The vulnerability is primarily due to the assumption that client.query() executes only a single query, allowing attackers to inject additional commands.

How can this SQL bypass vulnerability be exploited?

Attackers can inject SQL commands to bypass the read-only mode, perform unauthorized write operations, or cause denial of service.

What steps should be taken to secure the MCP Server?

Implement strict query validation, enforce single query transactions, and apply fine-grained access controls on the database server.

References

1. How to Mitigate SQL Bypass in MCP Servers
2. GitHub Kanban MCP Server Vulnerability
3. Node.js Secure Coding Practices
4. Bypassing Access Control in PostgreSQL

Conclusion

The identified vulnerability in Xata’s MCP Server highlights the importance of robust security practices in database interactions. By understanding the root cause and implementing the recommended mitigations, developers can protect their systems from SQL injection attacks and ensure the integrity and availability of their services.

For further insights and updates, follow Liran Tal on X and explore more on GitHub.