CVE-2026-17566
pgAdmin 4: RCE via backslash-escape mismatch in Import/Export Data query guard (incomplete defense, sibling gap to CVE-2025-13780)
No known exploitation. EPSS puts it in the 50th percentile. A vendor fix is available.
What to do
The vendor has published a fix. Version details are below where the sources state them.
Steps
Written by AI from the record- Check your pgAdmin 4 version and confirm whether it is older than 9.18.
- If you are on a version older than 9.18, plan to upgrade pgAdmin 4 to 9.18 as soon as possible.
- If you can’t upgrade immediately, restrict access to the Import/Export Data feature: allow only trusted users, and do not expose pgAdmin to the internet.
- After upgrading, re-verify that Import/Export Data pages and jobs work normally and that your pgAdmin admin/role access matches your intended permissions.
What it is
From the CVE record
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.
In plain language
Written by AI from the recordpgAdmin 4 before 9.18 has a bug in its Import/Export Data feature that can let an attacker run commands on your server if they can reach the feature with the right permissions—most small businesses should update soon, especially if you expose pgAdmin to the internet or untrusted users.
CVE-2026-17566 is a command-execution (RCE) flaw in pgAdmin 4 Import/Export Data where an incomplete query “safety check” mishandles backslash escaping in single-quoted strings, letting a crafted query escape the intended guard and reach psql execution.
If you're affected
- Full server command execution
- Data theft or corruption
- Service disruption
- Account compromise escalation
Exploitation
Where each signal puts this CVE on the scale from published to confirmed exploited.
- CISA KEV
Not in the catalog. CISA has not confirmed exploitation.
- Public exploits
No public exploit or proof of concept found in the sources we track.
- EPSS
0.7% chance of exploitation activity in the next 30 days, which ranks it in the 50th percentile of scored CVEs.
Exploit Prediction Scoring System, FIRST.org. A probability, not a confirmation.
Lifecycle
9 events over 5 days, from the signal feeds we watch.
- OpenVAS check addedpatch available, record updated
- Record updated
- Record updated
- Publishedweakness classified, att&ck mapped, record updated
Affected products
Technical detail
CVSS 3.1 vector
Open in the CVSS calculatorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Scored 9.9 by NVD.
How it is reached
- Attack Vector NetworkExploitable remotely over the network without any special conditions
- Attack Complexity LowNo special conditions — the attack can be reliably reproduced
- Privileges Required LowRequires basic user-level privileges
- User Interaction NoneNo user interaction needed — fully automated exploitation
Scope
- Scope ChangedThe exploit can affect other components (e.g. sandbox escape, host compromise from VM)
Impact if exploited
- Confidentiality HighTotal information disclosure — all data in the component is compromised
- Integrity HighTotal loss of integrity — attacker can modify any data in the component
- Availability HighTotal denial of service — the component is completely unavailable
Weaknesses
ATT&CK techniques
Mapped from the weaknesses above (CWE to ATT&CK), not observed in attacks.
Sources
Watch the software you run.
My Stack ranks new CVEs for your products by real-world exploitation, so the next serious one reaches you without reading every advisory.
We'll flag the next CVE, public exploit or patch for Pgadmin 4, not every advisory.
A free account adds
- The full version matrix and every affected product
- Exploit links, proofs of concept and Metasploit modules
- Email alerts for the products you watch
- The same data over REST API, MCP and CLI