--- id: "GHSA-fph8-pg5w-78fv" kind: "vulnerability" aliases: ["GHSA-fph8-pg5w-78fv"] title: "CVE-2026-87911 - Read-only enforcement bypass enabling operating system command execution in the SQL validation component of Amazon awslabs postgres-mcp-server" severity: "high" cvss: null epss: null exploited: false status: "open" category: "ai-tooling" products: [] ecosystems: [] tags: ["ai-agents", "ai-tooling", "aws", "lab-disclosure", "mcp", "postgresql", "python", "self-hosted"] not_affected_if: ["least-privilege-role", "managed-hosting", "version-1.1.7-or-later"] published_at: "2026-09-09T00:00:00+00:00" first_seen_at: "2026-10-24T20:05:36+00:00" updated_at: "2026-10-25T05:30:32+00:00" sources: [{"source": "lab", "url": "https://aws.amazon.com/security/security-bulletins/rss/2026-104-aws/", "first_seen_at": "2026-10-24T20:05:36+00:00"}] --- # CVE-2026-87911 - Read-only enforcement bypass enabling operating system command execution in the SQL validation component of Amazon awslabs postgres-mcp-server The awslabs postgres-mcp-server Python package before 1.1.7 has an OS command injection flaw in its read-only SQL validation: a crafted COPY ... TO PROGRAM statement placed in content the MCP server processes can run commands on the host of a self-managed PostgreSQL server. The advisory says an unauthenticated actor can plant the statement, but it fires when an authenticated user interacts with the server in its default read-only mode. _Summary, check and fix written by a model from the sources; labelled as such._ ## How to check - Check the installed version of the `awslabs.postgres-mcp-server` package (for example `pip show awslabs.postgres-mcp-server`); anything below `1.1.7` is exposed. - Check whether the server uses the self-managed PostgreSQL profile (PG_WIRE_PROTOCOL connection method) rather than a managed database. - Check whether the configured database role is a superuser or holds `pg_execute_server_program`, for example with `SELECT rolsuper FROM pg_roles WHERE rolname = current_user;` and `SELECT pg_has_role(current_user, 'pg_execute_server_program', 'MEMBER');`. ## Fix - Upgrade `awslabs.postgres-mcp-server` to `1.1.7` or later from PyPI. - Connect the MCP server with a dedicated, non-superuser role that does not hold `pg_execute_server_program`, granting only the CONNECT, USAGE and SELECT (or specific write) privileges the agent needs. - Do not connect as a superuser, rds_superuser or the cluster master user. ## Timeline - 2026-10-24T20:05:36+00:00 lab https://aws.amazon.com/security/security-bulletins/rss/2026-104-aws/ — AWS: CVE-2026-87911 - Read-only enforcement bypass enabling operating system command execution in the SQL validation component of Amazon awslabs postgres-mcp-server ## Documents - [advisory] AWS: CVE-2026-87911 - Read-only enforcement bypass enabling operating system command execution in the SQL validation component of Amazon awslabs postgres-mcp-server https://aws.amazon.com/security/security-bulletins/rss/2026-104-aws/ ## From the sources CVE-2026-87911 - Read-only enforcement bypass enabling operating system command execution in the SQL validation component of Amazon awslabs postgres-mcp-server ### 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: - Do not connect as a superuser, rds_superuser, or the cluster master user. Those roles bypass row-level security, can read credential catalogs (pg_authid, pg_user_mappings), and can terminate other sessions. - For read-only use, grant only CONNECT + USAGE + SELECT on the schemas the agent needs, and force read-only transactions at the role level. - For read/write use, grant only the specific INSERT/UPDATE/DELETE privileges required, scoped to the necessary schemas and tables. 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: - CVE-2026-87911 - GHSA-fph8-pg5w-78fv 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 aws-security@amazon.com with any security questions or concerns. --- _Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_