CVE-2026-17566: pgAdmin 4 Import/Export Command Injection Risk
TL;DR - Critical pgAdmin 4 flaw in the Import/Export Data tool can let a permitted user break out of the intended
\copy (...)wrapper. - Affects pgAdmin 4 users with access totools_import_export_data. - Patch exists in source, but the exact fixed release number was not confirmed from the available primary sources.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-17566 |
| CVSS | 9.9 |
| Attack vector | Authenticated application access to pgAdmin 4 Import/Export Data functionality |
| Privileges required | Yes; access to pgAdmin 4 with the tools_import_export_data permission |
| Patch available | Yes, source fix commit exists; exact fixed release number not confirmed from the available primary sources |
This is a critical vulnerability in pgAdmin 4 tied to how the application builds a psql \copy command for the Import/Export Data feature. The issue is not a generic SQL injection in the usual database sense. Instead, it is a parser mismatch and command-context injection problem that lets crafted input pass pgAdmin validation but be interpreted differently by psql.
For defenders, the practical implication is straightforward: if users can access the Import/Export Data tool, they may be able to supply a query that escapes the intended \copy (...) wrapper. The NVD description explicitly shows a payload pattern using TO PROGRAM, which raises the risk profile significantly because it moves from malformed query handling into potentially dangerous psql meta-command behavior.
What Is This Vulnerability?
The root cause is in the way pgAdmin 4 constructs a psql command line for Import/Export Data jobs. According to the NVD description, pgAdmin takes a user-supplied SQL query, injects it into a Jinja template, and passes the rendered \copy line to psql using --command. Before doing that, pgAdmin tries to ensure the user cannot break out of the expected (...) query wrapper.
That safety check relied on a custom routine named _is_query_parens_balanced(). The problem is that this checker modeled quoting behavior incorrectly. It treated \' as escaping a single quote, effectively assuming standard_conforming_strings was off. But PostgreSQL has defaulted standard_conforming_strings=on since version 9.1, and the NVD text notes this default applies across currently supported PostgreSQL versions 13 through 18.
That discrepancy matters because pgAdmin and psql then disagree about where a string literal ends. A crafted query can appear balanced to pgAdmin while psql interprets it as closing the string earlier, allowing the attacker to alter the \copy command syntax. The NVD provides this example:
SELECT 'a\') TO PROGRAM 'echo pwned' x'
In other words, pgAdmin’s pre-check says the input is safe enough to embed, while psql tokenizes it differently and may allow breakout into command context. This is why the issue is best understood as a command injection or command-context injection flaw in a psql \copy execution path, not simply a malformed parser bug with low impact.
Technical Notes
Relevant route: POST /import_export/job/<sid>
Permission gate: tools_import_export_data
Core behavior: user query -> Jinja template -> psql --command -> \copy (...)
-- Publicly described proof-of-concept style fragment from the NVD description
SELECT 'a\') TO PROGRAM 'echo pwned' x'
Who Is Affected?
The affected product is pgAdmin 4. The vulnerable component is specifically the Import/Export Data tool and the route described in the NVD entry: POST /import_export/job/<sid>. Exposure depends on whether users have access to that feature and whether the deployment delegates import/export permissions broadly across database administrators, developers, analysts, or support staff.
The NVD description also states the route is gated only by the ordinary and commonly granted tools_import_export_data permission. That is important for real-world risk assessment. This is not necessarily an unauthenticated internet-facing issue by default, but it also is not restricted to only top-level pgAdmin superusers. In many teams, this permission may be present in roles assigned for day-to-day operational tasks.
The exact pgAdmin 4 release range could not be confirmed from the available primary-source material provided here. The research notes confirm the product and code path, and they confirm that a fix commit exists, but they do not provide an authoritative vendor advisory or release note mapping the flaw to a specific version boundary. Because of that, defenders should avoid assuming that only a narrow subset of versions is affected.
The only version-related statement directly supported by the NVD description is about PostgreSQL support context: the parser mismatch is relevant under the default behavior of supported PostgreSQL versions 13-18. That statement does not define the vulnerable pgAdmin release range. In the absence of confirmed release boundaries, the safest operational assumption is: treat pgAdmin 4 installations with Import/Export Data access as potentially affected until you verify your installed version includes the fix associated with commit 1496fabe28c9f825f6bac0f0d000d9d3276322c3.
Technical Notes
# Example: identify the installed pgAdmin 4 package version on Debian/Ubuntu
dpkg -l | grep -i pgadmin
# Example: identify the installed pgAdmin 4 package version on RHEL-like systems
rpm -qa | grep -i pgadmin
# Example: if deployed in a container, inspect the image tag locally
docker images | grep -i pgadmin
CVSS Score Breakdown
The reported CVSS v3.x base score is 9.9, which places this issue firmly in the critical range. The precise vector string was not available from the source material provided here, so any breakdown of individual CVSS metric letters would be speculative. That said, the overall score aligns with the potential for high-impact abuse in an administrative tool that can influence psql command behavior.
Why so high? First, the flaw appears to enable a user with relatively common application privileges to cross a trust boundary inside the tool. The intended operation is “run a database export/import command based on a user query,” but the buggy validation can allow the user to alter the \copy command structure itself. That is a significant escalation in capability inside the application workflow.
Second, the NVD example specifically references TO PROGRAM, which is an inherently sensitive capability. Even without claiming confirmed remote code execution in every deployment, the possibility of redirecting \copy into program execution is enough to justify severe ratings because impact may extend beyond data exposure into command execution on the host running the invoked tooling, depending on deployment details and runtime constraints.
Because the exact vector string is unknown from the retrieved sources, defenders should be careful not to overfit remediation or risk treatment to guessed CVSS components. The safe interpretation is that authoritative scoring already views this as near-maximum severity and operationally urgent.
Technical Notes
Known from source material:
- CVSS v3.x Base Score: 9.9
- Exact vector string: not confirmed in the provided source set
- Operational takeaway: prioritize as critical despite missing vector string details
Exploitation Status
At the time of this writing, active exploitation in the wild is not confirmed from the provided source set. The available CISA KEV check indicates this CVE is not listed in the Known Exploited Vulnerabilities catalog. That means there is no CISA-backed confirmation of exploitation and no KEV-directed remediation deadline attached to this issue.
However, defenders should not interpret “not on KEV” as “not exploitable” or “safe to defer.” The NVD entry itself contains a PoC-style payload example, which is enough to establish that exploitation mechanics are publicly described. In addition, the public upstream issue and patch commit are available, which usually accelerates adversary understanding of root cause and exploitability even if there is not yet a polished standalone exploit repository.
So the defensible status statement is:
- PoC public? Yes, exploit mechanics are publicly described in the CVE/NVD text.
- Active exploitation confirmed? No confirmed evidence from the provided source set.
- CISA KEV listed? No, not currently listed.
For incident response and patch prioritization, this should be treated as a critical vulnerability with public technical disclosure and a realistic chance of copycat exploitation once administrators start discussing the bug and diffing the fix.
Technical Notes
Confirmed from available sources:
- Public patch commit: yes
- Public upstream issue: yes
- PoC-style query in NVD description: yes
- CISA KEV listing: no
- In-the-wild exploitation: not confirmed
How to Detect It
Detection should focus on use of the Import/Export Data feature, especially requests to the POST /import_export/job/<sid> route and suspicious SQL query payloads that include quote and parenthesis manipulation around \copy breakout conditions. Because the vulnerable behavior occurs when pgAdmin renders and passes a command to psql, both application logs and process execution telemetry are valuable.
At the application layer, review pgAdmin logs, reverse proxy logs, and any API monitoring that captures request paths or payload metadata. The most suspicious events will be Import/Export job submissions by users who do not normally perform exports, repeated failed job submissions, or query strings containing unusual combinations such as backslashes before single quotes, unmatched-looking parentheses, or keywords like TO PROGRAM.
At the host layer, monitor for psql execution spawned by the pgAdmin service account in patterns that differ from normal export jobs. If endpoint telemetry or EDR is available, look for child process creation or command lines containing --command, \copy, and TO PROGRAM. Even if your logging does not expose full query content, a shift in process ancestry or unexpected shell/program invocation near pgAdmin-driven export activity is worth investigating.
Technical Notes
Suspicious HTTP path pattern:
/import_export/job/
Suspicious content indicators:
TO PROGRAM
\')
\copy
--command
index=web OR index=proxy OR index=app_logs
("/import_export/job/" AND ("TO PROGRAM" OR "\\')" OR "\\copy" OR "--command"))
| stats count by src_ip, user, uri_path
# Example Sigma-style process logic to adapt for your EDR
title: Suspicious psql command execution from pgAdmin context
logsource:
product: linux
category: process_creation
detection:
selection:
Image|endswith: '/psql'
CommandLine|contains:
- '--command'
- '\copy'
keywords:
CommandLine|contains:
- 'TO PROGRAM'
condition: selection and keywords
level: high
# Example Linux triage: look for psql executions and suspicious command fragments
grep -R -Ei 'import_export/job|TO PROGRAM|\\copy|--command' /var/log/* 2>/dev/null
# If auditd is enabled, search recent psql executions
ausearch -x psql -ts recent
If you do not have strong application logging, assume potential blind spots. In that case, prioritize containment by restricting the Import/Export feature to a narrow admin group until patch status is verified.
Mitigation and Patching
A source-level fix exists in the public pgAdmin 4 repository at commit 1496fabe28c9f825f6bac0f0d000d9d3276322c3. What is not confirmed from the provided primary sources is the exact fixed pgAdmin 4 release number. Because inventing a release number would be irresponsible, the correct recommendation is: upgrade to the vendor release that includes this commit after verifying it in official release notes or package changelogs.
Until you confirm that release mapping, defenders should treat all pgAdmin 4 instances with Import/Export access as potentially vulnerable. If immediate patching is not possible, the most effective workaround is to remove or tightly restrict the tools_import_export_data permission and, where operationally acceptable, disable user access to the Import/Export Data feature entirely. This directly reduces the reachable attack surface described in the NVD entry.
You should also review whether pgAdmin runs in an environment where psql-initiated host-level actions would be especially dangerous. Hardening the service account, limiting child process execution, reducing shell access, and applying EDR rules around psql command lines can all lower post-exploitation impact while a tested upgrade is being prepared.
Technical Notes
# Debian/Ubuntu: check current package version before upgrading
apt-cache policy pgadmin4
# Upgrade to the vendor-fixed release once identified in official repos
sudo apt update
sudo apt install --only-upgrade pgadmin4
# RHEL-like systems: check current version
dnf info pgadmin4
# Upgrade once the fixed build is published in your enabled repository
sudo dnf upgrade pgadmin4
# Containerized deployment: pull and redeploy the vendor-fixed tag
docker pull dpage/pgadmin4:<verified-fixed-tag>
docker stop pgadmin4 && docker rm pgadmin4
docker run -d --name pgadmin4 dpage/pgadmin4:<verified-fixed-tag>
Workaround if you cannot patch immediately:
1. Remove or restrict tools_import_export_data permission
2. Limit Import/Export Data access to a minimal admin group
3. Monitor POST /import_export/job/<sid>
4. Alert on psql command lines containing \copy and TO PROGRAM
-- Operational note:
-- Do not assume changing PostgreSQL server settings alone remediates this issue.
-- The root cause is in pgAdmin's command construction and validation path.
Because the exact fixed version number is unknown from the provided sources, administrators should document the verification step explicitly in change records: confirm the installed build contains the fix commit or is listed in the vendor advisory as patched before closing the remediation ticket.
References
The primary reference for technical details is the NVD entry for CVE-2026-17566, which describes the root cause, affected feature, permission gate, and exploit mechanics. It is the authoritative source for the parser mismatch description and for the public PoC-style query example included in the vulnerability text.
The second key reference is the public fix commit in the pgAdmin 4 repository. That commit confirms a source-level remediation exists, even though the exact release mapping was not visible in the source material provided here. The public upstream issue is also relevant because it can help defenders track vendor discussion, release notes, and downstream package updates over time.
- NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-17566
- Fix commit: https://github.com/pgadmin-org/pgadmin4/commit/1496fabe28c9f825f6bac0f0d000d9d3276322c3
- Upstream issue: https://github.com/pgadmin-org/pgadmin4/issues/10213
- pgAdmin project site: https://www.pgadmin.org/news
For teams writing internal advisories, the safest summary is: critical authenticated pgAdmin 4 Import/Export vulnerability, public technical details available, no confirmed in-the-wild exploitation from current sources, patch exists but exact fixed release must be verified from official vendor release documentation.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.