| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| To pass a server's password to psql and to the utilities pgAdmin 4 runs as background processes, the server manager wrote it into pgAdmin's own process environment: as PGPASSWORD for the PSQL tool, and under a per-process variable for a utility. Nothing removed it afterwards. pgAdmin's environment is shared by every user's requests and copied into every process it starts, so in server mode another user's later PSQL session or utility inherited the password, and libpq used PGPASSWORD for any connection made without a password of its own, letting one user connect with another user's saved password.
The fix puts the password only into the environment built for the process that needs it and starts psql with a copy of pgAdmin's environment instead of the environment itself.
This issue affects pgAdmin 4: before 9.19. |
| When a server in pgAdmin 4 had no password file, client certificate or client key configured, or the configured one could not be found, pgAdmin left the parameter out of the connection and libpq fell back to the defaults of the operating-system account running pgAdmin: ~/.pgpass, ~/.postgresql/postgresql.crt and postgresql.key, or PGPASSFILE, PGSSLCERT and PGSSLKEY. In server mode any user could therefore connect to a server with the service account's saved passwords or client certificate, and supplying only a copy of its public certificate was enough for libpq to pair it with the service account's private key. A pg_service.conf entry, or a maintenance database name read as a connection string by pg_dumpall, could bring the same files back for the utilities.
The fix gives each of these parameters a value in server mode, the user's own file or otherwise a path that can never be opened, in the connection string, in the environment of the utilities and in the --dbname connection string that ranks above a service entry. Desktop mode is unchanged.
This issue affects pgAdmin 4: before 9.19. |
| 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. |
| pgAdmin 4's materialized view refresh passed the target database's name to psql's --dbname argument unchanged. libpq treats a --dbname value containing "=" (or a postgresql:// URI) as a full connection string, whose keywords override the host, port and other settings pgAdmin had supplied. A database whose name is such a string, which any role with CREATEDB can create, therefore redirected the psql process pgAdmin starts for the refresh to a host and port of the creator's choosing, and the connecting user's saved server password was presented to that endpoint. It also let the pgAdmin host be made to open connections to arbitrary addresses.
The same weakness was fixed for Backup, Restore, Maintenance and Import/Export Data in earlier releases (CVE-2026-86862); the materialized view refresh was the remaining caller. The fix routes the name through the same database_conninfo() helper, so libpq treats it strictly as a database name.
This issue affects pgAdmin 4: before 9.19. |
| Unauthenticated PHP Object Injection in FunnelKit Automations <= 3.8.6.1 versions. |
| Shop manager PHP Object Injection in Product Feed Manager <= 7.14.1 versions. |
| Subscriber PHP Object Injection in MasterStudy LMS <= 3.7.55 versions. |
| Unauthenticated PHP Object Injection in Zoho Flow <= 2.14.5 versions. |
| Unauthenticated PHP Object Injection in Gamic <= 1.19 versions. |
| Unauthenticated PHP Object Injection in Gamezone <= 1.1.11 versions. |
| Unauthenticated PHP Object Injection in EmojiNation <= 1.0.12 versions. |
| Unauthenticated PHP Object Injection in Bonbon <= 1.11 versions. |
| Unauthenticated PHP Object Injection in Avventure <= 1.1.12 versions. |
| Unauthenticated PHP Object Injection in Filmax <= 1.1.11 versions. |
| Unauthenticated PHP Object Injection in Muzicon <= 1.15 versions. |
| Unauthenticated PHP Object Injection in Motorix <= 1.11 versions. |
| Unauthenticated PHP Object Injection in Mission <= 1.22 versions. |
| Unauthenticated PHP Object Injection in Le Truffe <= 1.1.7 versions. |
| Unauthenticated PHP Object Injection in Legal Stone <= 1.2.11 versions. |
| Unauthenticated PHP Object Injection in GEO my WordPress <= 4.5.5.3 versions. |
