CVE-2026-116243: pgAdmin 4: Utility binary path can point at a shared storage directory

Published Oct 30, 2026

Updated

pgAdmin 4 runs pgdump, pgrestore, pgdumpall and psql from the binary path a user sets in their preferences. In server mode the binary path was refused only when it lay under the per-user storage directory (STORAGEDIR), not under a SHAREDSTORAGE directory, which ordinary users can upload files to. A user could therefore upload an executable to shared storage, point their binary path at it, and have pgAdmin run it as the operating-system account running pgAdmin. On POSIX, files created through pgAdmin are not executable, so this is exploitable where any file with an executable name can run, such as Windows server mode.

The fix checks the binary path against every SHAREDSTORAGE directory as well, after expanding $DIR, collapsing ".." and resolving symbolic links, compares directories in a way a different spelling on a case-insensitive filesystem cannot bypass, refuses a path containing a NUL, and enforces the check wherever binary paths are resolved, including for the PSQL tool.

This issue affects pgAdmin 4: before 9.19.

Event History

Oct 30, 2026

CVE Published

via MITRE·07:55 PM

Data Sourced

via MITRE·07:55 PM

DescriptionSeverityWeakness

Data Sourced

via NVD·08:17 PM

DescriptionSeverityWeakness

Frequently Asked Questions

Which deployments are realistically exposed to exploitation?

The issue is exploitable in server mode where ordinary users can upload files to a SHARED_STORAGE directory and where an uploaded file with an executable name can be run. The description specifically identifies Windows server mode as an example; on POSIX, files created through pgAdmin are not executable.

What access does an attacker need?

An attacker needs a pgAdmin user account with permission to upload a file into shared storage and set their utility binary path preference. They can then cause pgAdmin to run the uploaded executable as the operating-system account that runs pgAdmin.

Are default configurations affected?

The data does not establish whether shared storage is enabled or writable by ordinary users by default. Exposure depends on server mode, configured SHARED_STORAGE directories, and user upload permissions.

What should be done if an upgrade cannot be applied immediately?

Prevent ordinary users from uploading executable content into SHARED_STORAGE directories, and restrict or disable user-controlled utility binary paths where possible. This removes the described path from uploaded shared-storage files to execution by the pgAdmin operating-system account.

How can administrators determine whether they are affected?

Check whether the pgAdmin 4 version is earlier than 9.19, whether it runs in server mode, and whether ordinary users can upload files to any SHARED_STORAGE directory. Also identify whether the host can execute uploaded files by name, particularly on Windows server deployments.

CVE-2026-116243: pgAdmin 4: Utility binary path can point at a shared storage directory

Event History

Frequently Asked Questions

Which deployments are realistically exposed to exploitation?

What access does an attacker need?

Are default configurations affected?

What should be done if an upgrade cannot be applied immediately?

How can administrators determine whether they are affected?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are realistically exposed to exploitation?

What access does an attacker need?

Are default configurations affected?

What should be done if an upgrade cannot be applied immediately?

How can administrators determine whether they are affected?