Live › vulnerability › CVE-2026-85787
Go to dashboardThe SQL validation in AWS's awslabs postgres-mcp-server blocks only an incomplete list of disallowed statements, so crafted SQL can change data even when the server is meant to be read-only. An unauthenticated actor can plant that SQL in content an authenticated user later submits to the MCP server.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-24 18:43 UTC, 0h before NVD. All times on this page are UTC.
Teams that run the awslabs postgres-mcp-server package below version 1.1.7 against a Postgres database, where AI agents send SQL to it on behalf of users. Exposure depends on whether the database role has write privileges, since the blocklist is the only check that failed. Teams on 1.1.7 or later, or those not running this MCP server, can skip it.
No product ranges from the sources yet.
pip show awslabs.postgres-mcp-server and confirm it is at least 1.1.7awslabs.postgres-mcp-server PyPI package to 1.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("CVE-2026-85787")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.