{"id":"CVE-2026-116250","aliases":["EUVD-2026-114391","GHSA-2wvp-3w8r-39fh"],"status":"published","title":"pgAdmin 4: Files opened in a storage directory follow a symbolic link, hard link or FIFO planted after the containment check","description":"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.\n\nExploitation 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.\n\nThe 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.\n\nThis issue affects pgAdmin 4: before 9.19.","severity":{"version":"4.0","score":7.3,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00095,"percentile":0.00645,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":false},"cwes":["CWE-367","CWE-59"],"published":"2026-10-30T19:55:18Z","modified":"2026-11-09T15:04:02Z","products":[{"vendor":"pgadmin","product":"pgadmin_4"},{"vendor":"pgadmin.org","product":"pgadmin 4"}],"references":[{"url":"https://github.com/pgadmin-org/pgadmin4/issues/10647","tags":["issue-tracking","Issue Tracking","Patch","report"]},{"url":"https://github.com/pgadmin-org/pgadmin4/commit/99f5606e2ebc7c94c7acdbab877ce7de54bfc756","tags":["patch","Patch","fix"]},{"url":"https://github.com/pgadmin-org/pgadmin4/commit/c4321b9968342716f34bc5f10de6cac3c0567e68","tags":["patch","Patch","fix"]},{"url":"https://github.com/pgadmin-org/pgadmin4/commit/730d1e783c339ec696a1f77f2eee6f4b52cb6c37","tags":["patch","Patch","fix"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-116250","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-2wvp-3w8r-39fh"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/116xxx/CVE-2026-116250.json","tags":["advisory"]},{"url":"https://github.com/pgadmin-org/pgadmin4","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-116250","title":"pgAdmin 4: Files opened in a storage directory follow a symbolic link, hard link or FIFO planted after the containment check","description":"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.\n\nExploitation 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.\n\nThe 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.\n\nThis issue affects pgAdmin 4: before 9.19.","status":"published","published":"2026-10-30T19:55:18.713Z","modified":"2026-11-06T16:18:17.858Z","cvss":[{"version":"4.0","score":7.3,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N","level":"high","assessor":"cna"},{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L","level":"medium","assessor":"cna"}],"cwes":["CWE-367","CWE-59"],"updated_at":"2026-11-06T17:28:52.192546Z"}],"euvd":[{"id":"EUVD-2026-114391","description":"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.\n\nExploitation 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.\n\nThe 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.\n\nThis issue affects pgAdmin 4: before 9.19.","status":"published","published":"2026-10-30T19:55:18Z","modified":"2026-11-06T16:18:17Z","cvss":[{"version":"4.0","score":7.3,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N","level":"high"}],"updated_at":"2026-11-06T17:05:28.701654Z"}],"ghsa":[{"id":"GHSA-2wvp-3w8r-39fh","title":"In server mode pgAdmin 4 validates a path a user gives for a file in their storage directory with...","description":"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.\n\nExploitation 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.\n\nThe 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.\n\nThis issue affects pgAdmin 4: before 9.19.","status":"published","published":"2026-10-30T21:32:22Z","modified":"2026-10-30T21:32:49Z","cvss":[{"version":"4.0","score":7.3,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high"},{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L","level":"medium"}],"cwes":["CWE-59"],"updated_at":"2026-11-02T15:14:53.220001Z"}],"nvd":[{"id":"CVE-2026-116250","description":"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.\n\nExploitation 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.\n\nThe 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.\n\nThis issue affects pgAdmin 4: before 9.19.","status":"published","published":"2026-10-30T20:17:05.17Z","modified":"2026-11-09T15:04:02.48Z","cvss":[{"version":"4.0","score":7.3,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"},{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L","level":"medium","assessor":"secondary"}],"cwes":["CWE-59","CWE-367"],"updated_at":"2026-11-09T18:15:13.242943Z"}],"osv":[{"id":"CVE-2026-116250","title":"pgAdmin 4: Files opened in a storage directory follow a symbolic link, hard link or FIFO planted after the containment check","description":"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.\n\nExploitation 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.\n\nThe 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.\n\nThis issue affects pgAdmin 4: before 9.19.","status":"published","published":"2026-10-30T19:55:18.713Z","modified":"2026-11-11T02:48:42.031935342Z","cvss":[{"version":"4.0","score":7.3,"vector":"CVSS:4.0/AV:L/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-367","CWE-59"],"updated_at":"2026-11-07T03:08:01.156605Z"}]}}