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 and get full remote code execution on the pgAdmin server. The vulnerability is scored CVSS 8.8. For organizations running pgAdmin in shared server mode, where multiple database users share a single pgAdmin host, it is 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. Because it is widely adopted in enterprise environments, a vulnerability in pgAdmin can affect organizations across the industry.
Technical Information
Root Cause
The vulnerability is in the Import/Export query export functionality of pgAdmin 4. When a user starts a query export, pgAdmin builds a psql \copy metacommand by interpolating user-supplied input directly into the command template. pgAdmin applies no sanitization, escaping, or structural validation to the input before placing it in the metacommand string.
The \copy metacommand in psql follows the general form:
\copy (SELECT ...) TO 'filepath' WITH (FORMAT csv)
Because the user-supplied query sits inside the parentheses of \copy (...), an attacker who controls the query string can close the parenthetical context early and append arbitrary psql directives.
Attack Flow
-
An authenticated user opens 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 sends the output to an arbitrary OS command through psql'sTO PROGRAMdirective. The attacker replacescmdwith whatever shell command they want to execute on the pgAdmin server. -
Alternatively, the attacker can inject:
) TO '/path'This writes the copy output to an arbitrary file path on the server, which gives the attacker arbitrary file write.
-
The
format,on_error, andlog_verbosityfields are also interpolated raw into the metacommand template without validation. Each of them is an injection point independent of the query field.
Why Null Bytes Matter
Before 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. An attacker could use this discrepancy to bypass whatever validation the Python layer did have and still deliver a malicious payload to psql.
Fix Mechanics in Version 9.15
Commit 13badc62c adds several layers of defense:
| Input Field | Previous Vulnerable Behavior | Version 9.15 Security Control |
|---|---|---|
| query | Interpolated raw into copy template, allowing context breakout | Parens balance validator (_is_query_parens_balanced()) and newline normalization applied |
| format | Interpolated raw without validation | Strict allow list enforced (csv, text, binary) |
| on_error | Interpolated raw without validation | Strict allow list enforced (stop, ignore) |
| log_verbosity | Interpolated raw without validation | Strict allow list enforced (default, verbose) |
The parens balance validator, _is_query_parens_balanced(), tracks parenthesis depth in the query and is modeled on the strtokx tokenizer that psql itself uses. It stops an attacker from breaking out of the \copy (...) context with unbalanced closing parentheses.
The patch also normalizes line breaks to spaces, so an attacker cannot end the \copy metacommand with a newline character and start a new psql command on the next line. It tightens type and gating checks throughout the code path, and malformed payloads now return a clean 400 error rather than a 500 server error.
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, and any one of them could exploit this vulnerability to execute commands on the server.
Vendor Security History
pgAdmin has had a metacommand-related vulnerability before. 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 it let attackers race a restore process to re-enable metacommands, which resulted in reliable command execution on the pgAdmin host. The recurrence of metacommand injection suggests a systemic problem in how pgAdmin builds and secures its interface with the underlying psql command-line tool.
The pgAdmin Development Team has been responsive in both cases and shipped fixes promptly after disclosure. Organizations that depend on pgAdmin should still pay attention to the pattern, 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
