CVE-2026-87911: AWS postgres-mcp-server's read-only mode can be bypassed to run OS commands
The SQL validator in awslabs.postgres-mcp-server before 1.1.7 didn't block every statement that can touch the system in its default read-only mode. A crafted COPY ... TO PROGRAM statement hidden in content the agent processes can run operating system commands on a self-managed PostgreSQL host, when the MCP server connects with a highly privileged database role.
What it is
Read-only mode relied on an application-level blocklist of SQL verbs, and COPY ... TO PROGRAM got through it.
AWS says an unauthenticated actor could plant the statement in content that is processed when an authenticated user works with the MCP server, so an agent can end up running it for them.
Exploitation needs the PG_WIRE_PROTOCOL connection method and a database role with superuser or pg_execute_server_program. Servers connected with a minimal-privilege role are not affected, because the database refuses the command.
How to check
- Affected: awslabs.postgres-mcp-server (PyPI) before 1.1.7.
- Check which Postgres role your MCP server config connects as. Superuser, rds_superuser or the cluster master user is the risky setup.
How to fix
- Upgrade awslabs.postgres-mcp-server to 1.1.7 or later.
- Connect the MCP server with a dedicated least-privilege role: for read-only use, only CONNECT, USAGE and SELECT on the schemas the agent needs, with read-only transactions forced at the role level.
pip show awslabs.postgres-mcp-server | grep -i versionSources
- criticalCVE-2026-114612: LiteLLM proxy lets an internal user forge an admin token and run commands
- criticalMalicious npm packages posing as AI agent tools: agentic-awesome-skills, x402-prompt-injection-scan and formatting-subtitles-for-claude
- criticalCVE-2026-114125: A malicious website can tamper with your project through a running Storybook dev server
- criticalCVE-2026-102503: Google Agent Mesh let any peer call MCP backends through an unchecked ingress