CVE-2026-87911 - Read-only enforcement bypass enabling operating system command execution in the SQL validation component of Amazon awslabs postgres-mcp-server

What it is

AWS bulletin 2026-104-AWS (published 09/09/2026) for CVE-2026-87911, an OS command injection in the read-only enforcement of the SQL validation component of awslabs.postgres-mcp-server (PyPI) before 1.1.7. Fixed in 1.1.7.

How it works

The server runs a default read-only mode enforced by an application-level SQL validation blocklist. A crafted COPY ... TO PROGRAM statement slips past that blocklist. The bulletin frames the delivery precisely: the crafted statement is placed into content that is processed when an authenticated user interacts with the MCP server — i.e. the malicious SQL rides in on content the agent handles, so the attacker need not authenticate to the server directly. If the connecting database role holds superuser or pg_execute_server_program, COPY TO PROGRAM runs an arbitrary OS command on the PostgreSQL host.

Preconditions / Affected

• awslabs.postgres-mcp-server before 1.1.7.
• Self-managed PostgreSQL deployment profile using the PG_WIRE_PROTOCOL connection method.
• The configured database role holds superuser or pg_execute_server_program. Without one of these privileges, COPY TO PROGRAM has nothing to execute — which is why the role-scoping workaround is a real boundary, not just hygiene.

What to do

Upgrade to 1.1.7. Beyond that, the bulletin's core argument is that the database — not the application blocklist — should enforce the boundary, via a dedicated least-privilege role:

• Do not connect as 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.
• Read-only use: grant only CONNECT + USAGE + SELECT on the schemas the agent needs, and force read-only transactions at the role level.
• Read/write use: grant only the specific INSERT/UPDATE/DELETE privileges required, scoped to the necessary schemas and tables.

The intended posture is defense in depth: the application blocklist plus a database-enforced minimal role, so that even a query that slips the blocklist is bounded by what the role can actually do.

Caveats

The bulletin states the blocklist is application-enforced and can be bypassed (this CVE is one such bypass); it is explicit that the role-privilege control is the stronger of the two because the database enforces it "regardless of what SQL reaches it." Treat the blocklist alone as insufficient.