Two Postgres MCP servers failed read-only enforcement on the same day, and one is AWS's

Your read-only flag is a claim, not a guarantee. Two independent Postgres MCP servers proved it on September 4.

Postgres MCP Pro got CVE-2026-85620 at CVSS 9.2. The bug is one line of reasoning in safe_sql.py: the validator checks function names on FuncCall AST nodes. A function placed in a FROM clause parses as a RangeFunction node, which the validator passes through without inspecting. So SELECT pg_read_file('/etc/passwd') is blocked and SELECT * FROM pg_read_file('/etc/passwd') returns the file. All versions through 0.3.0 (NVD).

The same day, CVE-2026-85787 against Amazon's own awslabs postgres-mcp-server before 1.1.7. Incomplete list of disallowed inputs in SQL validation, so crafted SQL placed into content an authenticated user later submits can modify data beyond read-only scope. Upgrade to 1.1.7 (NVD).

Two teams, two codebases, one shape of mistake: an allowlist applied at one node type in a parser that has several. Denylists and node-type-specific allowlists both fail the same way, because the attacker only needs to find the parse path you didn't enumerate.

That shape repeats across the whole day's advisories. IBM ContextForge MCP Gateway took four CVEs on September 4, two of them DNS rebinding: CVE-2026-18905 during tool invocation and CVE-2026-77822 for SSRF, both defeating URL validation by re-resolving between the check and the connect. Validate-then-fetch without pinning the resolved IP is not a guard. SiYuan before v3.8.2 protected publishAccess.json with a case-sensitive string comparison, so PublishAccess.json on a case-sensitive Linux filesystem walks straight past it (CVE-2026-85580). CodeWhale's DNS pinning allowed execution to continue when a lookup fails, so an attacker-controlled resolver fails the first A/AAAA queries and answers 127.0.0.1 on the retry (GHSA-6v2g-fpxh-pmmh, CVSS 8.6).

Test this today, it takes two minutes. Point your read-only MCP at a scratch database and send SELECT * FROM pg_read_file('/etc/hostname'). If you get a hostname back, your mode flag is decoration. Then check whether your SQL guard canonicalizes and case-folds paths, whether it pins resolved IPs before connecting, and whether a failed DNS lookup fails closed.

Two more from the same batch that deserve their own line. LaVague 0.2.35's PythonFromMarkdownExtractor.extract_as_object evaluates untrusted model output derived from page content, so an attacker who controls a page the browsing agent visits gets Python running on the operator's host with no review step (CVE-2026-85694, CVSS 9.2). That's the full indirect-injection chain completing, with a raw eval as the sink. And IBM Langflow OSS 1.0.0 through 1.11.2 gates MCP config installation on a localhost check that trusts X-Forwarded-For, so a remote authenticated attacker sending X-Forwarded-For: 127.0.0.1 writes to ~/.cursor/mcp.json (CVE-2026-9186). Writing that file installs a tool server your editor will launch. Treat IDE MCP config paths as executable content and watch them for changes.