GHSA-j7mp-839j-jrm7: pgEdge Postgres MCP Server read-only mode can be bypassed by SQL statement smuggling through query_database
pgEdge Postgres MCP Server enables SQL queries against PostgreSQL databases through Model Context Protocol compatible clients. Prior to 1.1.0, querydatabase on a readonly connection could send unrecognized statements through pgx Exec without bind parameters, selecting PostgreSQL's simple query protocol and allowing multiple semicolon-separated statements in one request. A caller could combine transaction or session state changes with database writes, and pooled session state could leave later calls writable, when the connecting role held write privileges. The flaw affected deployments relying on readonly as a safety boundary, could compromise integrity and availability, and did not add confidentiality impact beyond the reads already permitted by the connection. This issue is fixed in 1.1.0.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pgEdge Postgres MCP Serverto a version that resolves this vulnerability.Fixed in 1.1.0
Event History
Frequently Asked Questions
Which deployments are exposed to write or availability impact?
Deployments using versions before 1.1.0 that rely on a read_only connection as a safety boundary are affected when the connecting PostgreSQL role has write privileges. The issue does not add confidentiality impact beyond the reads already allowed to that connection.
What does an attacker need to exploit the issue?
An attacker needs access to invoke query_database through an MCP-compatible client and must be able to submit SQL that includes multiple semicolon-separated statements. Exploitation depends on the connection role having write privileges.
Are default read-only protections sufficient?
No. The read_only mode could be bypassed because unrecognized statements were sent through pgx Exec using PostgreSQL's simple query protocol, allowing statement smuggling and session or transaction state changes before writes.
What can be done if upgrading is not immediately possible?
Do not rely on read_only as the sole safety boundary. Use a connecting PostgreSQL role without write privileges to prevent the smuggled statements from performing database writes.
How can I determine whether my deployment is affected?
Check whether the pgEdge Postgres MCP Server version is earlier than 1.1.0, whether query_database is available on read_only connections, and whether those connections authenticate as roles with write privileges. Pooled connections may retain session state that leaves later calls writable.