CVE-2026-116250
MediumCVSS 6.5Summary
In server mode pgAdmin 4 validated a user-supplied file path in the storage directory with check_access_permission() and then opened it by name using a plain open() or passed the path to utilities (pg_dump, pg_dumpall, pg_restore, psql) and to servers.json export/import and import file listing. Swapping in a symbolic or hard link or a FIFO between the check and the open redirected the operation outside the storage directory, allowing a file to be written, overwritten or read, or loaded into a table, as the pgAdmin operating-system account. This affects pgAdmin 4 before 9.19.
Risk Assessment
Exploitation requires write access to the storage backend as a different operating-system user (e.g., shared or network-mounted storage) and winning the race, so the risk is limited, but in such environments it can lead to unauthorized file read, write or overwrite and request hangs via FIFO.
Recommendation
Update pgAdmin 4 to version 9.19 or later. Restrict write access to storage directories to the pgAdmin account only and avoid shared or network-mounted storage for these directories.
Other vulnerabilities in pgAdmin 4
See all- CVE-2026-116252Medium
In pgAdmin 4, materialized view refresh passed the target database name to psql's --dbname argument unchanged. libpq treats a value containing "=" or a postgresql:// URI as a full connection string, allowing redirection to a chosen host and port and disclosure of the saved server password.
- CVE-2026-116251Medium
In pgAdmin 4, changing a user's password (by the user or an administrator) did not invalidate existing sessions. A session established before the change, e.g. on another device or by someone with the old password, stayed logged in until it expired.
- CVE-2026-116249High
In pgAdmin 4 server mode before 9.19, get_complete_file_path() only stripped leading slashes before joining paths, so a path such as ../<another user>/.pgpass could name another user's file. The sslkeylogfile parameter was passed to libpq unchanged, and make_conninfo() quoted parameter values but not names, allowing additional keyword=value pairs to be smuggled in.
- CVE-2026-116248Medium
In pgAdmin 4 server mode, the server API create and update endpoints stored the "shared" flag and shared username, letting any user able to register a server share it with everyone. The servers.json import had a similar gap, as a non-administrator's "Shared" entries were removed only after validation.
- CVE-2026-116247High
In pgAdmin 4 before 9.19, when a server had no password file, client certificate, or client key configured, or the configured file could not be found, pgAdmin omitted the parameter and libpq fell back to the defaults of the operating-system account running pgAdmin. In server mode any user could therefore connect using the service account's saved passwords or client certificate.
- CVE-2026-116246Medium
In pgAdmin 4, the server password was written into pgAdmin's own process environment (as PGPASSWORD for the PSQL tool and under a per-process variable for a utility) and never removed. In server mode the environment is shared across all users' requests and copied into started processes, so another user could inherit the password and use it to connect.
- CVE-2026-116245High
In pgAdmin 4 server mode, libpq looks up connection services in the service file of the operating-system account, allowing users to use that account's credentials or certificate files. The vulnerability affects versions before 9.19 and can lead to unauthorized access to database servers.
- CVE-2026-116244High
In pgAdmin 4 server mode, removing KRB5CCNAME caused the Kerberos library to fall back to the service account's default credential cache, allowing any user to connect as the service principal. The vulnerability affects versions before 9.19 and also includes bypassing gssencmode=disable and SSPI behavior on Windows.
- CVE-2026-116243High
In pgAdmin 4 server mode, the user-set binary path was not checked against SHARED_STORAGE directories, allowing an executable to be uploaded and run as the pgAdmin service account. The vulnerability is especially relevant on Windows where files can be executable, and affects versions before 9.19.
- CVE-2026-116242High
In pgAdmin 4 server mode, the sshtunnel library always loaded unencrypted private keys from the service account's ~/.ssh and read its SSH configuration, allowing any user to configure a tunnel using the service account's identity. The vulnerability affects versions before 9.19.
Original NVD description (English source)
In server mode pgAdmin 4 validates a path a user gives for a file in their storage directory with check_access_permission() and then opened it by name. Several places opened it with a plain open() or handed the path to a utility that opened it later: the servers.json export and import and the import file listing, and the files given to pg_dump, pg_dumpall, pg_restore and psql by Backup, Restore and Import/Export Data. A symbolic link swapped in at the file or at any parent directory between the check and the open redirected the operation outside the storage directory, so a file could be written, overwritten or read, or loaded into a table, as the operating-system account running pgAdmin. A hard link to an outside file, which O_NOFOLLOW does not detect, and a FIFO, which could hang a request, had the same effect. CVE-2026-86861 fixed this for the File Manager's save_file; these were the remaining paths. Exploitation requires creating such a link or FIFO inside the user's storage directory. pgAdmin offers no way to do so, and the per-user storage directories belong to the pgAdmin account, so this requires write access to the storage backend as a different operating-system user, for example a shared or network-mounted storage directory, and winning the race. The fix opens each file by walking down from the storage directory one component at a time with O_NOFOLLOW, accepting only a regular file with one link, and passes the utilities the open descriptor (/dev/fd/N) on Linux. Error messages no longer include the server path. This issue affects pgAdmin 4: before 9.19.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS