Our agent uses the AWS Labs Postgres, MySQL or DocumentDB MCP server in its default read-only mode. Which advisories showed that read-only mode could be bypassed, which versions fix them, and is read-only mode safe to rely on now?

What should I check, step by step?

1. Check the installed versions: postgres-mcp-server before 1.1.7, mysql-mcp-server 1.0.21 or earlier (there was no 1.0.22) and documentdb-mcp-server before 1.0.12 are affected. The newest on PyPI on November 11, 2026 were 1.2.4, 1.1.5 and 2.0.1.

2. Look at the dates, not just the CVEs: the fixed releases came out months before the advisories (Postgres 1.1.7 on June 25, MySQL 1.0.23 on July 2, DocumentDB 1.0.12 on April 8, 2026), so a pinned install that was never upgraded is the usual way to still be exposed.
3. Connect each server with a role that can only read: in Postgres, CONNECT, USAGE and SELECT on the schemas the agent needs, read-only transactions forced at the role level, and not a superuser, rds_superuser or the cluster master user. In MySQL, SELECT only. In DocumentDB, a user without write privileges.
4. In Postgres, never grant the agent's role pg_execute_server_program, pg_read_server_files or pg_write_server_files. PostgreSQL's docs say they allow running programs and reading or writing files on the database server and could be used to gain superuser-level access.
5. Don't add --allow_write_query to make a demo work and leave it there. Without it the servers run their read-only checks; with it they run whatever the role permits.
6. Treat every value the agent reads from the database, tickets, documents or web pages as untrusted input that may contain SQL aimed at the next query.
7. Point read-only agents at a read replica or reader endpoint where you have one, so a missed write has nowhere to land.

Which AWS Labs Postgres, MySQL and DocumentDB MCP server advisories bypassed read-only mode, and which versions fix them?

Postgres, CVE-2026-85787 (GHSA-pwr4-hmph-gqgc, medium, CVSS 3.1 6.5, published September 4, 2026): an incomplete list of disallowed inputs in the SQL validation component let crafted SQL modify data beyond the read-only scope. Postgres, CVE-2026-87911 (GHSA-fph8-pg5w-78fv, critical, CVSS 3.1 9.6, published September 9, 2026): the read-only check didn't block every SQL verb that performs system-level operations, so a COPY ... TO PROGRAM statement could execute operating-system commands on the host of a self-managed PostgreSQL server, when the PG_WIRE_PROTOCOL connection method was used with a role holding superuser or pg_execute_server_program. Both affect versions before 1.1.7.

• MySQL, CVE-2026-85788 (GHSA-x25m-ph3m-3r9q, medium, CVSS 3.1 5.5, published September 9, 2026): read-only enforcement matched SQL text with patterns that expected literal whitespace between keywords, and MySQL treats comments as whitespace, so SQL interleaved with comments passed the check and still ran. Its impact depends on the MySQL user holding the FILE privilege. It affects 1.0.21 and earlier; the fix in 1.0.23 strips comments before matching and rejects MySQL conditional comments, the /*! ... */ form that MySQL's documentation says the server parses and executes.
• DocumentDB, CVE-2026-18954 (GHSA-j694-4m5j-w8hc, medium, CVSS 3.1 5.5, published August 5, 2026): in the default read-only mode the insert, update and delete tools refused writes, but the aggregate tool didn't check pipeline stages, so $out and $merge wrote to the database anyway. It affects versions before 1.0.12.

How can SQL or a pipeline get past an MCP database server's read-only mode without anyone logging in?

The Postgres and MySQL bypasses don't need anyone to log in to the MCP server. The Postgres advisories describe crafted SQL placed in content that is processed when an authenticated user interacts with the server, and the MySQL advisory says anyone able to influence the SQL string, including through prompt injection against the model driving the client, can submit statements the check misses. A comment field, a support ticket or a web page the agent reads is enough to carry the instruction.

• PostgreSQL's documentation shows why the role matters. COPY with PROGRAM runs the command on the database server as the operating-system user PostgreSQL runs as, and only superusers or roles granted pg_execute_server_program (or the server file-access roles) may use it. The advisory says users who connected the MCP server with a minimal-privilege role weren't affected, because the database itself denied the operation.
• The same pattern holds for the other bypasses. A data-changing statement, a FILE-based write or an aggregation with $out or $merge all need a role that can write; the DocumentDB advisory's own workaround is a database user without write privileges. Each bypass got past the MCP server's check and then depended on what the connected role was allowed to do.

Is an AWS Labs MCP database server's read-only mode a security boundary?

AWS says no, in its own words. The MySQL server's README says its read-only mode "is a best-effort SQL-text safeguard, not a security boundary" and that the actual boundary is the database role you connect with; it says the Postgres, MSSQL and Oracle sibling servers carry the same caveat. Its table of what the check doesn't catch includes quoted-identifier tricks and mutating verbs added in future MySQL releases.

• The current Postgres README describes a stronger guard: each query is parsed with PostgreSQL's own parser, only read statement shapes are allowed, multi-statement input is rejected, it fails closed on parse errors, and command execution, server file access and network calls such as dblink are always refused. It still calls the enforcement best effort and recommends a minimal-privilege role, with no pg_read_server_files, pg_write_server_files or pg_execute_server_program, and no USAGE on foreign data wrappers or foreign servers.
• So keep both layers. The server's check gives a fast, readable refusal and catches mistakes; the role's grants decide what can actually happen. When you need the agent to write, scope the role to the tables it needs and put a person in front of each write query rather than switching the whole server to --allow_write_query.