The Blocklist Was AWS's Own. It Did Not List Every Way Past Read Only.

Two vendors, two months apart, published an advisory admitting the same category of gap in a PostgreSQL MCP server's own read only mode. Crystal DBA's came with a reporter's proof of concept this desk could run directly, an open pull request this desk could apply and test, and an unpatched tagged release this desk could confirm still carried the bug. AWS Labs' advisory came with none of that: a corrected version already two months old, a vendor description that names the CWE class without naming the input, and a current README that states, in AWS's own words, why a blocklist was never meant to be trusted alone. This record treats that difference in what is knowable as itself part of what it reports, rather than filling the gap with an inferred mechanism borrowed from the other vendor's own, separately documented bypass.

What the advisory itself states

GitHub Security Advisory GHSA-pwr4-hmph-gqgc, fetched directly by this session, formally assigns CVE-2026-85787 on 4 September 2026, CWE-184, Incomplete List of Disallowed Inputs, at a CVSS 3.1 base score of 6.5, Moderate, vector AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N, against the PyPI package awslabs.postgres-mcp-server, versions before 1.1.7, corrected in 1.1.7. Its own description states that an incomplete list of disallowed inputs in the SQL validation component could allow an authenticated user's own submitted content to modify data beyond the read only scope the server was intended to hold that interaction to, and its own mitigation guidance recommends connecting through a dedicated, minimal privilege PostgreSQL role rather than a superuser account. The advisory carries no proof of concept, no linked commit and no linked pull request that this session's own fetch of the page returned, and its listed contact is aws-security@amazon.com.

A shipped fix, read against its own timeline

This record fetched the project's own PyPI release history directly. Version 1.1.6 published 3 June 2026. Version 1.1.7, the version GHSA-pwr4-hmph-gqgc names as corrected, published 25 June 2026, twenty two days later and more than two months before the advisory's own 4 September 2026 publication date. Five further releases have shipped since: 1.1.8 on 22 July 2026, 1.1.9 on 28 July 2026, 1.1.10 on 5 August 2026, 1.1.11 on 10 August 2026, and 1.2.0 on 26 August 2026, the project's own current latest version at the time of this record, itself adding a further least privilege connection guardrail according to the project's own release history. Every one of these five releases postdates the fix this advisory names. This record treats that timeline as establishing only what it establishes: a deployment tracking the project's own released versions at any point after 25 June 2026 was not running the code this advisory describes as vulnerable, a materially different lifecycle position than Crystal DBA's own Postgres MCP Pro, where this desk separately confirmed the identical gap it ran against a tagged release also reproduces, unpatched, against that project's current default branch.

The vendor's own documentation already states the boundary this bypass crossed

This record fetched the project's own current README directly rather than relying on the advisory's own summary of what the server does. Its own wording, quoted directly: when the MCP server runs without the operator supplied allow write query flag, it rejects queries that appear to mutate data or session state, implemented with a keyword and function blocklist, DML and DDL verbs such as INSERT, UPDATE and DROP, session state statements such as SET, RESET, DISCARD and LOAD, anonymous code blocks, and high impact functions including pg_terminate_backend, pg_sleep and the advisory lock family. The same document, in its own words, states the limitation directly: treat this as a best effort, defense in depth mechanism, not a security boundary, naming obfuscation, quoted identifiers and new server or extension functions as categories a blocklist cannot enumerate in full, and states plainly, do not rely on it as your only control. Its own recommended control is a dedicated Postgres role holding only the privileges it needs, explicitly not a superuser, rds_superuser or the cluster master user, so that the database itself enforces the boundary regardless of what SQL reaches it. This record did not have to infer this boundary from the advisory. The vendor's own current documentation already states it, in language this record confirms was fetched directly rather than paraphrased from a third party summary.

Why this record connects to, rather than duplicates, Crystal DBA's own occurrence

A companion record on this desk already ran Crystal DBA's own Postgres MCP Pro validator directly against a function name blocked in one syntactic position and permitted in an equivalent one, confirming precisely how a check that exists and correctly enforces its own allow list against a FuncCall node reached directly never runs at all against the identical call nested inside a RangeFunction node's own functions attribute. That record grounds the canonical weakness this dataset already carries as representation dependent authorization, an operation blocked in one syntactic form authorized in an equivalent one: a check that works, demonstrated against at least one representation, left unreached by an equally valid alternate representation of the identical operation. This record does not claim AWS's own advisory demonstrates that same specific mechanism. CWE-184, Incomplete List of Disallowed Inputs, is a broader class than a single traversal gap in one parser's node taxonomy, and could equally describe a keyword the list never included at all, a construct the same class this record's own read of the current README names directly as the blocklist's own acknowledged limitation, obfuscation, quoted identifiers, or a new server or extension function. What this record does assert, because two independently maintained implementations now each state it in their own words, is the broader property both occurrences instantiate: a declared read only mode, enforced by a name or keyword check against SQL a parser has already produced, is only as complete as the set of representations and inputs that check was built and tested to recognize, and AWS's own current documentation states that limitation about its own blocklist more plainly than most vendors state it about their own security controls at all.

What this record deliberately did not chase

A separate, older AWS Labs postgres-mcp-server issue, GitHub issue 911, opened 22 July 2025 and since closed, reports the opposite defect, an operator supplied readonly false argument still being refused as though read only were forced on. This record read that issue directly, confirmed it concerns a configuration flag failing to permit writes rather than a validation gap failing to block them, and excludes it from this occurrence as unrelated, a distinct bug filed against an earlier version and a different failure direction entirely.

The Authority Provenance ledger

Authority grantor. The operator who deploys awslabs.postgres-mcp-server, omits the allow write query flag specifically to hold an agent to read only interaction, and configures the PostgreSQL role the server authenticates as.

Caller identity. An authenticated user interacting with the MCP server, per the advisory's own description; the advisory names no further detail about which MCP client or agent context this record can independently confirm.

Caller mandate. Read only interaction with the connected PostgreSQL database, the entire reason the operator ran the server without the write query flag rather than granting broader authority outright.

Intermediary. The server's own SQL validation component, described by the advisory and confirmed directly by this record's own read of the current README as a keyword and function blocklist evaluated before a query reaches PostgreSQL.

Intermediary credential. The PostgreSQL role the server's connection authenticates as, whatever privileges that role separately holds, exactly the boundary the project's own current documentation names as its own recommended, database enforced control.

Downstream target. Data within the intended read only scope, per the advisory's own description of the consequence, modified beyond that scope by content an authenticated user submitted.

Failed limit. Named by AWS on 9 September 2026, and no longer unknown to this record. CVE-2026-87911, GHSA-fph8-pg5w-78fv and AWS Security Bulletin 2026-104-AWS each state, in AWS's own words, that the pre 1.1.7 SQL validation component did not block all SQL verbs that can perform system level operations in its default read only mode, and name the omitted construct directly: a crafted COPY ... TO PROGRAM statement. The earlier CVE-2026-85787 record's open question about which input the list omitted is answered by the vendor itself, and the stated consequence widens from data modification beyond read only scope to possible operating system command execution on the host of a self managed PostgreSQL server.

Inherited assumption. That the blocklist's own enumeration of DML and DDL verbs, session state statements and named dangerous functions was complete enough to hold the server to read only behavior on its own, an assumption the project's own current documentation now states directly should never have been made, describing the same mechanism as best effort and defense in depth rather than a security boundary.

Credential binding. Not established by available evidence for this specific occurrence; the advisory does not state whether the demonstrated consequence depended on the connected role's own separate privileges, unlike Crystal DBA's own occurrence, where this desk's companion record states that dependency directly.

Destination binding. Absent on whatever input the pre 1.1.7 blocklist failed to enumerate; present and correctly enforced, per the vendor's own documentation, against every keyword, statement and function that same documentation names explicitly.

Challenge authority. None on the MCP layer for whatever input bypassed the blocklist prior to 1.1.7; whatever the connected PostgreSQL role's own privileges separately permit or refuse once a query reaches the server, the same distinct and already correctly enforced boundary the project's own documentation names as its recommended control.

Revocation or modification. Shipped. Version 1.1.7 published 25 June 2026, confirmed directly against the project's own PyPI release history, more than two months before the advisory's own publication date, with five further releases since.

Recovery path. Upgrade to 1.1.7 or later, per the advisory's own stated remediation, independently confirmed current at 1.2.0, released 26 August 2026, as of this record; combined, per the project's own current documentation, with connecting as a dedicated, minimal privilege PostgreSQL role rather than a superuser, rds_superuser or the cluster master user.

Exploitation. Unknown. No source available to this record states this was exploited against a production deployment, and the advisory itself carries no proof of concept.

Provenance evidence quality. Strong for the advisory's own stated facts and for the fix timeline: this record fetched the GHSA advisory, the project's own current README and its own PyPI release history directly, rather than through a third party summary. Weaker, by the evidence's own nature rather than by any gap in this session's own effort, for the underlying mechanism: AWS's own advisory names no proof of concept and no specific omitted input, and no source at the exact pre 1.1.7 vulnerable version was reachable to this session, so this record cannot state the mechanism to the depth its companion record achieved for Crystal DBA's own, separately reproduced occurrence. Direct fetch of aws.amazon.com's own security bulletin for this CVE and of awslabs.github.io's own hosted documentation were both blocked by this session's network egress policy on every attempt; this record relies on the GitHub Security Advisory Database's own record and on the project's own source repository instead, both fetched directly.

Update, 10 September 2026: AWS names the omitted input, and it reaches the operating system

The open question this record published on 7 September 2026, which specific input the pre 1.1.7 blocklist failed to enumerate, is now answered by the vendor itself. On 9 September 2026 AWS published Security Bulletin 2026-104-AWS and GitHub Security Advisory GHSA-fph8-pg5w-78fv, assigning CVE-2026-87911 against the same package and the same affected boundary, versions before 1.1.7, corrected in 1.1.7. This session fetched both pages directly, HTTP 200 in each case, and read them rather than a third party summary. Their shared description states that an OS command injection weakness in the read only enforcement of the SQL validation component in 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. The advisory's own Impact section states plainly that the component does not block all SQL verbs that can perform system level operations in that default mode.

Two things change materially, and this record states both as the sources state them. First, the mechanism is no longer unknown: the omitted input is a named PostgreSQL construct, COPY ... TO PROGRAM, which the blocklist's own enumeration of DML and DDL verbs, session statements and named functions did not cover, exactly the enumeration limit the project's own README already called best effort rather than a security boundary. Second, the established effect widens. CVE-2026-85787 described modification of data beyond the read only scope, integrity only, at CVSS 3.1 base score 6.5, Moderate, scope unchanged. CVE-2026-87911 is scored by the same advisory page at CVSS 3.1 base 9.6, Critical, vector AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, with a changed scope and high confidentiality, integrity and availability impact, and carries two weaknesses, CWE-78, OS command injection, alongside the CWE-184 incomplete disallowed input list the earlier CVE carried alone. The consequence class moves from inside the database to the host running it.

The preconditions are stated by AWS and this record repeats them without widening them. The path applies to a self managed PostgreSQL deployment profile reached through the PG_WIRE_PROTOCOL connection method, where the configured database role holds superuser or pg_execute_server_program. AWS states directly that users who connect the MCP server with a minimal privilege database role are not affected, because the database itself would deny the operation regardless of the application layer bypass. That is the same database enforced control the project's own README already recommended and this record already reported, now confirmed by the vendor as the boundary that actually holds when the application layer one does not. AWS credits Mordehai Attia of Corsen AI and Ryan von Brubeck through coordinated disclosure. The corrected version remains 1.1.7, published 25 June 2026, so the fix timeline this record established for the earlier CVE covers this one too.

Where this sits in the pattern

Crystal DBA's own Postgres MCP Pro already showed a function name allow list correctly enforced against one syntactic representation of a call and never reached against an equivalent one, a mechanism this desk independently ran and confirmed. AWS Labs' own postgres-mcp-server, an unrelated codebase maintained by a different organization, now independently states in its own advisory and its own current documentation that its comparable blocklist based read only enforcement carries the same shaped limitation in general, without this record being able to confirm the same specific traversal mechanism drives it. This desk's wider argument, that execution authority has to be evaluated against the action a system actually takes rather than assumed from an earlier, adjacent declaration, extends here to a declared mode a server's own operator chose specifically to narrow what an agent could do through it: read only described only the dimension AWS Labs' own blocklist was built to enforce, and this occurrence, independently arising at a second vendor, is further evidence for a durable property this dataset already carries rather than grounds for a new one, that a policy which correctly blocks the representations and inputs it was tested against is not, on that basis alone, a policy that has been tested against every representation or every input the same effect can be reached through.

What this record does not establish

This record does not claim CVE-2026-85787 has been exploited against a real awslabs.postgres-mcp-server deployment, that its underlying mechanism matches Crystal DBA's own RangeFunction traversal gap, that every deployment connects as a PostgreSQL role holding privileges beyond what the connecting operation itself required, that the project's own blocklist offers no protective value, or that a deployment still pinned to a version before 1.1.7 is not exposed. Where the evidence available to this record does not establish a fact, this record states it as unknown rather than inferring it from the pattern a different vendor's own, separately reproduced occurrence already established.