Introduction
An authenticated user with access to pgAdmin 4's Import/Export query export feature can inject OS commands directly into the underlying psql \copy metacommand, achieving full remote code execution on the pgAdmin server. For organizations running pgAdmin in shared server mode, where multiple database users share a single pgAdmin host, this vulnerability (scored CVSS 8.8) represents a direct path from a low privilege database account to complete server compromise.
pgAdmin is the most popular and feature rich open source administration and development platform for PostgreSQL. It provides a graphical interface for database management across multiple platforms and languages, and its widespread adoption in enterprise environments means vulnerabilities in pgAdmin carry broad potential impact across the industry.
Technical Information
Root Cause
The vulnerability resides in the Import/Export query export functionality of pgAdmin 4. When a user initiates a query export, pgAdmin constructs a psql \copy metacommand by interpolating user supplied input directly into the command template. No sanitization, escaping, or structural validation is applied to the input before it is placed into the metacommand string.
The \copy metacommand in psql follows the general form:
\copy (SELECT ...) TO 'filepath' WITH (FORMAT csv)
Because the user supplied query is placed inside the parentheses of \copy (...), an attacker who can control the query string can close the parenthetical context prematurely and append arbitrary psql directives.
Attack Flow
-
An authenticated user navigates to the Import/Export dialog in pgAdmin 4 and selects the query export option.
-
In the query field, the attacker provides a payload such as:
) TO PROGRAM 'cmd'This closes the
\copy (...)context and redirects output to an arbitrary OS command via psql'sTO PROGRAMdirective. The attacker replacescmdwith whatever shell command they wish to execute on the pgAdmin server. -
Alternatively, the attacker can inject:
) TO '/path'This redirects the copy output to an arbitrary file path on the server, enabling arbitrary file write.
-
The exploitation surface is not limited to the query field. The
format,on_error, andlog_verbosityfields are also raw interpolated into the metacommand template without validation. Each of these fields provides an independent injection point.
Why Null Bytes Matter
Prior to the fix, null bytes in the query string could cause a C string truncation mismatch between Python's validation layer and the actual psql execution. Python treats null bytes as part of the string, while C based psql truncates at the first null byte. This discrepancy could be leveraged to bypass any validation that did exist in the Python layer while still delivering a malicious payload to psql.
Fix Mechanics in Version 9.15
Commit 13badc62c introduces several layers of defense:
| Input Field | Previous Vulnerable Behavior | Version 9.15 Security Control |
|---|---|---|
| query | Raw interpolated into copy template allowing context breakout | Parens balance validator (_is_query_parens_balanced()) and newline normalization applied |
| format | Raw interpolated without validation | Strict allow list enforced (csv, text, binary) |
| on_error | Raw interpolated without validation | Strict allow list enforced (stop, ignore) |
| log_verbosity | Raw interpolated without validation | Strict allow list enforced (default, verbose) |
The parens balance parser, _is_query_parens_balanced(), tracks parenthesis depth in the query and is modeled on the strtokx tokenizer used by psql itself. This ensures an attacker cannot break out of the \copy (...) context by injecting unbalanced closing parentheses.
The patch also normalizes line breaks to spaces, preventing an attacker from terminating the \copy metacommand via a newline character and starting a new psql command on the next line. Malformed payloads now return a clean 400 error rather than a 500 server error, tightening type and gating checks throughout the code path.
Affected Systems and Versions
This vulnerability affects pgAdmin 4 versions 9.4 through 9.14. The fix is included in pgAdmin 4 version 9.15, released on May 11, 2026.
Shared server mode deployments are at elevated risk because multiple authenticated users share the same pgAdmin host, meaning any one of those users could exploit this vulnerability to execute commands on the server.
Vendor Security History
This is not the first metacommand related vulnerability in pgAdmin. Earlier in 2026, CVE-2026-1707 affected pgAdmin version 9.11 with a Restore restriction bypass via key disclosure. That vulnerability also occurred in server mode and allowed attackers to race a restore process to re enable metacommands, resulting in reliable command execution on the pgAdmin host. The recurrence of metacommand injection issues suggests a systemic challenge in how pgAdmin constructs and secures its interface with the underlying psql command line tool.
The pgAdmin Development Team has been responsive in both cases, shipping fixes promptly after disclosure. However, the pattern warrants attention from organizations that depend on pgAdmin, particularly those running it in server mode.
References
- OS command injection in Import/Export query export (CVE-2026-7816) · Issue #9899
- CVE Record: CVE-2026-7816
- Fix commit: Prevent OS command injection in Import/Export query export
- pgAdmin 4 v9.15 Release Notes
- pgAdmin 4 v9.15 Released (PostgreSQL announcement)
- pgAdmin Official Site
- pgAdmin 4 Download (Windows)
- GHSA-3p7x-94q9-jq9x: pgAdmin Restore restriction bypass (CVE-2026-1707)
- NVD: CVE-2026-1707



