AWS Postgres MCP Server Read Only Validation Bypass Allows Commands on Self Managed Database Hosts
Amazon has published security bulletin 2026-104-AWS covering CVE-2026-87911, an operating system command injection weakness in the awslabs.postgres-mcp-server Python package. The package implements a Model Context Protocol server that lets AI agents query PostgreSQL databases, and the flaw sits in the read-only enforcement logic of its SQL validation component. All versions before 1.1.7 are affected, but only in the self-managed PostgreSQL deployment profile using the PG_WIRE_PROTOCOL connection method, and only where the configured database role holds superuser or the pg_execute_server_program privilege. The issue was reported through coordinated disclosure by Mordehai Attia of Corsen AI and Ryan von Brubeck, and fixed in version 1.1.7 on PyPI.
The bulletin describes the mechanism in terms of PostgreSQL's COPY … TO PROGRAM statement, which hands a command to the database host's shell. An unauthenticated actor plants a crafted COPY … TO PROGRAM statement inside content that the MCP server later processes when an authenticated user interacts with it. Because the SQL validation layer fails to block that construct, the statement slips past the server's default read-only mode and reaches the database. If the role the MCP server connects with carries superuser or pg_execute_server_program rights, PostgreSQL executes the embedded command on the operating system of the self-managed server. The attacker therefore never needs database credentials of their own, only a path for their text to reach an agent session that someone else authenticates.
The pattern here is the one that makes AI agent tooling awkward to defend: a trust boundary enforced in application code rather than by the database, defeated by content the agent was simply asked to read. Where the flaw lands, the consequence is not limited to data exposure, because command execution on the PostgreSQL host puts credentials, backups and lateral movement into reach. Exposure concentrates on teams running self-managed PostgreSQL and connecting the MCP server with an over-privileged role, since the bulletin scopes the issue to that deployment profile and connection method. FIRST EPSS currently places the probability of exploitation in the next 30 days at 1.7 percent, and neither the bulletin nor the GitHub advisory reports exploitation in the wild. The bulletin is classified as Important, signalling a flaw that merits attention on a planned cycle rather than an incident response footing, though environments still running an unfixed version with a superuser role remain squarely in the described attack path.
Attack Surface
Database, Server OS, Supply Chain (Third-party vendors)
Tactics
Initial Access, Execution, Privilege Escalation
Techniques
- T1190 – Exploit Public-Facing Application
- T1059 – Command and Scripting Interpreter
- T1068 – Exploitation for Privilege Escalation
- T1078 – Valid Accounts
SuperPRO's Threat Countermeasures Procedures
- Upgrade the awslabs.postgres-mcp-server Python package to version 1.1.7 or later from PyPI, which contains the fix for CVE-2026-87911 (GHSA-fph8-pg5w-78fv); inventory any pinned requirements files, container images or agent toolchains that still install an earlier release.
- Replace the database role used by the MCP server with a dedicated least-privilege role and remove superuser, rds_superuser, cluster master and pg_execute_server_program membership from it, since those grants are what allow COPY … TO PROGRAM to reach the host shell.
- For read-only agent use, grant only CONNECT, USAGE and SELECT on the specific schemas the agent needs and force read-only transactions at the role level with ALTER ROLE <agent_role> SET default_transaction_read_only = on.
- For read/write agent use, grant only the exact INSERT, UPDATE and DELETE privileges required, scoped to named schemas and tables, rather than reusing an existing application or admin role.
- Establish exposure against the conditions named in bulletin 2026-104-AWS by querying pg_roles and pg_auth_members for the role the MCP server connects with on self-managed clusters using the PG_WIRE_PROTOCOL connection method, confirming whether it holds superuser or pg_execute_server_program membership.
- Identify every deployment still below the fixed release by checking the installed version with pip show awslabs.postgres-mcp-server on each agent host, since the bulletin lists all versions prior to 1.1.7 as affected.
- Keep the dedicated least-privilege role described in bulletin 2026-104-AWS in place after moving to version 1.1.7, so the MCP server does not revert to a shared application or admin role that again carries pg_execute_server_program rights.
