CVE-2026-17566 in pgAdmin
Summary
by MITRE • 07/31/2026
pgAdmin 4's Import/Export Data tool builds a psql \copy (...) command line by interpolating a user-supplied SQL query into a Jinja template and passing the rendered line to psql via --command. To stop an attacker from breaking out of the (...) wrapper, create_import_export_job() (route POST /import_export/job/<sid>, gated only by the ordinary, commonly-granted tools_import_export_data permission) validated the query with a hand-written parenthesis-balance checker, _is_query_parens_balanced(). That checker always treated a backslash before a single quote (\') as escaping the quote, i.e. as if standard_conforming_strings were off. PostgreSQL has defaulted standard_conforming_strings to on since 9.1 (2010), the default on every PostgreSQL version pgAdmin 4 currently supports (13-18); under that default psql's own \copy tokenizer treats \ as an ordinary character, so a single quote immediately after it closes the string literal. A query such as SELECT 'a\') TO PROGRAM 'echo pwned' x' was therefore accepted as "balanced" by pgAdmin's checker (which believed the ) was still inside the string), while psql, run through the actual rendered command line, closes the string at that point and treats the following ) as the end of the wrapping \copy (...) subquery, exposing an attacker-chosen TO PROGRAM '<command>' clause that psql executes via popen() -- independent of a subsequent syntax error later on the same line. This is the same class of bug as CVE-2025-12762/CVE-2025-13780 (RCE via psql meta-command/COPY injection during PLAIN-format dump restore), reached through an independently written defense in a different module (Import/Export Data rather than Restore) that had its own, different logic bug (inverted backslash-escape semantics rather than a BOM-defeated regex anchor).
The fix rejects any backslash inside a single-quoted string in the query outright, rather than picking one of the two possible psql interpretations. This is intentionally conservative: because the correct interpretation of \ depends on the target server's standard_conforming_strings setting, which the checker cannot reliably know at validation time, refusing the query is safer than guessing.
This issue affects pgAdmin 4: from the introduction of _is_query_parens_balanced() before 9.18.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/31/2026
The vulnerability in pgAdmin 4's Import/Export Data functionality stems from a flawed input validation mechanism that enables command injection through improper handling of SQL query strings. The system employs a Jinja template to construct psql \copy commands by interpolating user-supplied queries, creating a potential attack surface where malicious input could be executed with elevated privileges. This flaw specifically targets the create_import_export_job() function accessible via POST /import_export/job/<sid> endpoint, which is gated only by the commonly-granted tools_import_export_data permission, making it an attractive target for privilege escalation attacks.
The technical core of the vulnerability lies in the _is_query_parens_balanced() validation routine, which incorrectly processes backslash-escaped single quotes within SQL strings. This checker assumes standard_conforming_strings is disabled, treating \ as an escape character for single quotes regardless of the actual PostgreSQL server configuration. Since PostgreSQL has defaulted standard_conforming_strings to on since version 9.1 in 2010, and pgAdmin 4 supports versions 13-18 where this setting is standard, the validation logic becomes fundamentally incompatible with how psql actually processes these inputs. The discrepancy creates a scenario where a query like SELECT 'a\') TO PROGRAM 'echo pwned' x' appears balanced to pgAdmin's validator but executes as a legitimate psql command when passed through the actual execution pipeline.
When the malformed query reaches psql, the system interprets \ as an ordinary character rather than an escape sequence, causing the string literal to close prematurely at the backslash-quoted single quote. This premature closure allows the attacker-controlled TO PROGRAM clause to be treated as part of the \copy command structure, enabling arbitrary command execution through psql's popen() function. The vulnerability demonstrates a classic injection flaw where input validation does not align with execution semantics, allowing attackers to bypass security controls and execute arbitrary code on the system hosting pgAdmin.
This issue represents a variant of similar vulnerabilities previously identified as CVE-2025-12762 and CVE-2025-13780, which also exploited psql meta-command injection during data import operations. However, while those vulnerabilities targeted the restore functionality with different root causes related to inverted backslash-escape semantics, this particular flaw emerged from a separate validation module within the Import/Export Data tool. The attack vector shares commonalities with CWE-74 and CWE-94 in terms of code injection and command execution through improper input handling, while also reflecting patterns seen in ATT&CK technique T1059.001 for command and scripting interpreter usage.
The mitigation strategy adopted by the fix involves a conservative approach that rejects any backslash character appearing within single-quoted string literals in user-supplied queries. This decision prioritizes safety over functionality by eliminating the ambiguous interpretation entirely rather than attempting to determine the correct behavior based on potentially unknown server configurations. The solution addresses the fundamental issue of relying on server settings that cannot be reliably determined at validation time, instead taking a zero-tolerance stance toward input patterns that could lead to command injection regardless of target configuration.
The vulnerability affects pgAdmin 4 installations from the introduction of _is_query_parens_balanced() function before version 9.18, indicating that systems running affected versions are exposed to this privilege escalation risk. This represents a critical security flaw in database administration tools where a single validation error can provide attackers with arbitrary command execution capabilities, potentially compromising entire database server environments through the pgAdmin interface.