Live › vulnerability › CVE-2026-87911
Go to dashboardThe awslabs postgres-mcp-server Python package before 1.1.7 fails to block COPY ... TO PROGRAM statements in its read-only SQL validation. Crafted content processed by an authenticated user of the MCP server can make the PostgreSQL host run operating system commands.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-24 20:05 UTC, 0h before NVD. All times on this page are UTC.
Teams running the AWS Labs Postgres MCP server against a self-managed PostgreSQL server, where the configured role is a superuser or holds pg_execute_server_program. The read-only default mode does not stop the flaw, so the database role is what bounds the risk. Teams on RDS or Aurora-managed profiles, or with a least-privilege role, face a lower risk, and anyone already on 1.1.7 or later is fixed.
No product ranges from the sources yet.
pip show awslabs.postgres-mcp-server and confirm it is 1.1.7 or later.1.1.7 or later from PyPI.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
CVE-2026-87911 - Read-only enforcement bypass enabling operating system command execution in the SQL validation component of Amazon awslabs postgres-mcp-server
Bulletin ID: 2026-104-AWS Scope: AWS Content Type: Important (requires attention) Publication Date: 09/09/2026 12:30 PM PDT
Description:
awslabs.postgres-mcp-server is a python package that implements a Postgres MCP server. We found CVE-2026-87911, where an OS command injection weakness in the read-only enforcement of the SQL validation component in Amazon awslabs postgres-mcp-server before 1.1.7 might allow an unauthenticated actor to execute operating system commands on the host of a self-managed PostgreSQL server by placing a crafted COPY ... TO PROGRAM statement into content that is processed when an authenticated user interacts with the MCP server in its default read-only mode.
Impacted versions:
awslabs.postgres-mcp-server before 1.1.7, self-managed PostgreSQL deployment profile (PG_WIRE_PROTOCOL connection method) where the configured database role holds superuser or pg_execute_server_program.
Resolution:
This issue has been addressed in awslabs postgres-mcp-server (python package) version 1.1.7 in pypi.
Workarounds:
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 Mordehai Attia (Corsen AI) and Ryan von Brubeck for collaborating on this issue through the coordinated vulnerability disclosure process.
Please email [email protected] with any security questions or concerns.
This page as .md · .json · in your agent: get_signal("CVE-2026-87911")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.