Arpit Jain

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.