Restricted mode in Postgres MCP Pro was designed as the safe configuration for exposing a PostgreSQL database to an AI agent. It limits operations to read-only transactions and validates incoming SQL against an allowlist. CVE-2026-85620, disclosed this week with a CVSS v4.0 score of 9.2, bypasses that entire control with a single syntactic trick.
The vulnerability, reported by George Chen on June 6, 2026, stems from an incomplete validation in the package’s SQL safety layer. The safe_sql.py module checks function calls against an allowlist only when they appear as FuncCall Abstract Syntax Tree nodes. But a function placed in a FROM clause parses as a RangeFunction node — a type the validator permits without checking the function name. The result: SELECT pg_read_file('/etc/passwd') is blocked, but SELECT * FROM pg_read_file('/etc/passwd') executes and returns the file contents.
The impact extends beyond the database. An attacker exploiting this bypass can read arbitrary files accessible to the PostgreSQL server process — system configurations, credentials, TLS keys — effectively escalating from database queries to host filesystem access. The attack requires no authentication to the restriction logic itself; any MCP client or AI agent with access to the restricted-mode interface can trigger it. As of this writing, no patched release beyond version 0.3.0 exists. A fix is under review as an open pull request against the crystaldba/postgres-mcp repository.
The IONIX Threat Center advisory and VulnCheck advisory both classify the issue as CWE-863 (Incorrect Authorization). The CVE record confirms all versions through 0.3.0 are affected.
The Postgres MCP Pro package is not obscure. It is an open-source MCP server by Crystal DBA that provides AI agents with database health checks, index tuning, and query execution against PostgreSQL. The restricted mode it offers is the configuration operators are told to use in production — the one that is supposed to make agent-database interaction safe without requiring a separate read-only database role.
That assumption is now broken, and it fits a pattern. The MCP ecosystem has grown to 97 million monthly SDK downloads and more than 10,000 active public servers, with 28 percent of Fortune 500 companies running MCP servers in production, according to a 2026 Synvestable report. But the security model has not kept pace. A Department of Defense Cyber Security Information document from June 2026 flagged that MCP proliferation has outpaced security model maturity. Fifty percent of MCP server builders cite security and access control complexity as their biggest challenge, per the Zuplo State of MCP report.
This week alone has produced a cluster of AI infrastructure vulnerabilities: CVE-2026-82526, a critical SQL injection in R2R (the retrieval framework), and CVE-2026-85695, an authentication bypass in FastChat’s model serving layer. Three concurrent CVEs across the AI agent stack — retrieval, serving, and database access — all disclosed within the same week.
For operators running Postgres MCP Pro in production, the immediate steps are concrete. Do not rely on restricted mode as a security boundary against untrusted or agent-generated SQL. Run the MCP server against a PostgreSQL role that lacks pg_read_server_files and other filesystem privileges. Monitor logs for queries using pg_read_file, pg_ls_dir, or pg_stat_file in FROM clauses. Apply network-level restrictions on which clients and agents can reach the MCP server. And monitor the postgres-mcp repository for a patched release.
The deeper issue is architectural. Application-layer safety controls — allowlists, AST parsers, read-only transaction modes — are being deployed as if they were database-level security boundaries. They are not. When the enforcement point sits in middleware that an attacker can influence through prompt injection or crafted SQL, the trust model collapses at the first parser gap. The fix for Postgres MCP Pro will close this specific bypass, but the pattern of trusting application-layer abstractions to substitute for database-level RBAC is the structural problem the MCP ecosystem has not solved.