


























In the world of software development, security is paramount. This story unfolds around the MCP Database Server, a tool designed to facilitate agentic workflows with various database servers, including PostgreSQL. However, a critical vulnerability was discovered, allowing attackers to bypass the “read-only” mode, leading to potential denial of service and unauthorized data access.
This article brings the tale of a vulnerability, its exploitation, and the necessary steps to mitigate such risks.
The MCP Database Server, developed by ExecuteAutomation, is a tool that provides an interface for interacting with different database servers. It is distributed via the npm package @executeautomation/database-server and is publicly available on the npm registry.
The server is designed to operate in a “read-only” mode, allowing only data retrieval operations. However, a flaw in its security controls has been identified, exposing it to potential abuse.
The vulnerability, assigned CVE-2025-59333, stems from improper access control in the server’s code. The server attempts to enforce a “read-only” mode by checking if a query string starts with SELECT. This naive approach fails to account for the complexities of SQL queries and the capabilities of database servers like PostgreSQL.
// 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 server’s security mechanism relies on the assumption that queries starting with SELECT are inherently safe. However, this is not the case. PostgreSQL, for instance, allows for complex operations within a SELECT query, including calling stored procedures and executing administrative commands.
An attacker can exploit this vulnerability by crafting a SELECT query that performs unintended operations. For example, a query like SELECT some_function_that_updates_data(); can execute a stored procedure that modifies data. Similarly, SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE ...; can terminate active database connections, leading to a denial of service.
SELECT pg_sleep(5 * 60);SELECT pid, usename, state, query FROM pg_stat_activity;SELECT pg_terminate_backend(PID);These steps demonstrate how an attacker can disrupt database operations using the MCP interface.
The vulnerability poses significant security risks, including:
To mitigate these risks, the following measures are recommended:
The story of the MCP Database Server serves as a cautionary tale about the importance of robust security controls. By understanding the vulnerabilities and implementing the recommended measures, developers can protect their systems from similar threats. For more insights and security research, follow Liran Tal on Twitter and explore his work on GitHub.
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。