Executive brief
pgAdmin 4's Backup feature fails to properly validate the database name supplied by users, allowing authenticated attackers to inject arbitrary options into the pg_dump command. This can result in writing backup files to arbitrary locations on the server's filesystem, potentially destroying pgAdmin's configuration database, or redirecting backups to an attacker-controlled database server while capturing encrypted credentials. Any authenticated user with backup permissions is vulnerable.
Technical details
The Backup tool appends a client-supplied 'database' field from the /backup/job/<sid>/object request directly to the pg_dump argument vector without validation. Because pg_dump uses getopt_long for option parsing, arguments beginning with a dash (e.g., '--file=/arbitrary/path') are interpreted as options, allowing an attacker to override pgAdmin's intended --file parameter and write output anywhere the pgAdmin process has permissions. Additionally, libpq expands database names containing an equals sign as full connection strings, enabling an attacker to inject connection keywords that override --host and --port, redirecting pg_dump to a malicious server. Since pgAdmin exports the decrypted database password in PGPASSWORD before executing pg_dump, this credential is transmitted to the attacker's endpoint. The vulnerability is reachable by any authenticated user with the tools_backup permission (default User role). The fix moves the database name to the PGDATABASE environment variable, which libpq treats as a literal value and never expands.
Affected products
- pgAdmin Project pgAdmin 4 before 9.18
Timeline
- 2026-09-17: disclosed