Live › vulnerability › GHSA-pwr4-hmph-gqgc
Go to dashboardThe SQL validation component in awslabs postgres-mcp-server, meant to enforce read-only access, does not block every disallowed input. Crafted SQL placed in content submitted to the MCP server can modify data beyond the read-only scope.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-24 18:43 UTC. All times on this page are UTC.
Teams that run the awslabs postgres-mcp-server, or a fork of it, connected to a Postgres database, especially where an AI agent passes content that an authenticated user submits into the server. Deployments on version 1.1.7 or later are not affected by this flaw, and the sources do not describe any other configuration that changes exposure.
No product ranges from the sources yet.
pip show postgres-mcp or pip freeze | grep -i postgres-mcp; anything below 1.1.7 is affected1.1.7 or laterEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
CVE-2026-85787 - An incomplete list of disallowed inputs in the SQL validation component in Amazon awslabs postgres-mcp-server to modify data beyond the read-only scope
Bulletin ID: 2026-101-AWS Scope: AWS Content Type: Important (requires attention) Publication Date: 09/04/2026 13:00 PM PDT Last Updated Date: 09/08/2026 09:45 AM PDT
Description:
We have identified CVE-2026-85787, an incomplete list of disallowed inputs in the SQL validation component in Amazon awslabs postgres-mcp-server before version 1.1.7 might allow an unauthenticated actor to modify data beyond the read-only scope by placing crafted SQL into the content that is submitted when an authenticated user interacts with the MCP server.
Impacted versions: any pypi package version < 1.1.7
Resolution:
This issue has been addressed in version 1.1.7. We recommend upgrading to the latest version and ensuring any forked or derivative code is patched to incorporate the new fixes.
Workarounds:
Run the MCP server as a minimal-privilege Postgres role
The strongest control is to connect the MCP server using a dedicated Postgres role that has only the privileges it actually needs, so that the database itself enforces the boundary regardless of what SQL reaches it. In particular:
Combining a minimal-privilege role (database-enforced) with the blocklist (application-enforced) gives you defense in depth: even if a query slips past the blocklist, the role's privileges still bound what it can do.
References:
Acknowledgement:
We would like to thank Ashwak N for reporting this issue and working with us as part of our coordinated issue disclosure process.
Please email [email protected] with any security questions or concerns.
This page as .md · .json · in your agent: get_signal("GHSA-pwr4-hmph-gqgc")