CVE-2026-17566: pgAdmin 4 RCE disclosed (CVSS 9.4), same root as incompletely patched CVE-2025-13780

pgAdmin 4 disclosed critical RCE CVE-2026-17566 (CVSS 9.4) in the Import/Export Data Jinja template that converts SQL to psql copy commands. Backslash-escape mismatch lets an authenticated attacker break out of the query wrap and run arbitrary system commands via psql. Same class as the incomplete 2025 CVE-2025-13780 fix.

Overview

pgAdmin 4 is the PostgreSQL community's most widely used open-source web admin console. More than 15 million developers and DBAs use it daily. Researchers disclosed a critical RCE in the Import/Export Data tool. Assigned CVE-2026-17566. CVSS 9.4 (Critical).

The bug sits in the Jinja template that converts SQL into psql copy commands. Backslash escaping does not match between incoming SQL and psql. An authenticated user can break out of the query wrap and make psql run arbitrary system commands. This is not unauthenticated internet RCE. It needs an enterprise pgAdmin account. Because the console is the DBA daily admin surface, post-auth code execution still makes it a useful pivot.

Technical details

pgAdmin 4 Import/Export Data lets users import and export SQL query results from the client. To turn an SQL string into a backend `psql ... \copy ... FROM` statement, the backend concatenates via a Jinja template. The design was supposed to keep user SQL inside `\copy ... FROM STDIN`. The code only handled some escape characters. Backslash escaping on user input is inconsistent:

• pgAdmin escapes at input time using Python string expressions;

• psql uses a different parse model. Multi-escape, `$`, and double-quote handling differ.

An authenticated user can submit SQL that looks like a query but breaks out of `\copy`. Injecting `\;`, special escape characters, or multi-line query structure can make psql treat a later token as a new command. That command can call psql helpers such as `\!` (shell) or `\copy ... PROGRAM` to run arbitrary system code. The code runs as the pgAdmin service process.

Triggering it requires injecting commands into this path. Given routine debug, repro, and data-import use, plus common enterprise "submit a query for the project owner" workflows, exploit likelihood is not low. Advisory notes this is the same class as CVE-2025-13780 from 2025. The earlier fix did not fully cover the same escape model. Patching only the reported sink is not enough. All escape paths need a systematic rewrite.

Impact

• Severity: 9.4 (Critical). Authenticated, but not high-privilege. Most DBA accounts suffice.

• Cross-service pivot: enterprise pgAdmin is often on the internal network. Compromise can pivot to backend PostgreSQL, storage, and backups.

• Same template path and escape logic as CVE-2025-13780. The community is moving psql invocation from Jinja concatenation to parameterized forms. You still need the new release to block this.

Mitigation

• Upgrade pgAdmin 4 immediately to a build that includes this CVE fix. Source-only enterprise deployments can pull from the official pgAdmin APT repo or RPM packages.

• Restrict Import/Export: disable or limit the import tool until you are on a patched version. Superuser-only Import, file-upload limits, size and content limits.

• Isolate the pgAdmin service. Keep it on the internal network that actually needs it. Avoid cross-department access. Push SSO / MFA.

• Audit backslash-escape paths in any internal product that takes SQL input and calls psql / psql copy. Re-check consistency between the two parsers.

• Detection: in EDR / logs, monitor `pgAdmin` process behavior. Unknown users invoking psql, then `\copy ... PROGRAM`. Alert early.

References

• PostgreSQL community announcement: pgAdmin 4 patch release

• pgAdmin 4 GitHub Advisory (CVE-2026-17566)

• NVD CVE-2026-17566 details

• CVE-2025-13780 2025 fix history