{"api_version":"1","generated_at":"2026-10-31T00:17:58+00:00","cve":"CVE-2026-116250","urls":{"html":"https://cve.report/CVE-2026-116250","api":"https://cve.report/api/cve/CVE-2026-116250.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-116250","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-116250"},"summary":{"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.","state":"PUBLISHED","assigner":"PostgreSQL","published_at":"2026-10-30 20:17:05","updated_at":"2026-10-30 20:17:05"},"problem_types":["CWE-59","CWE-367","CWE-367 CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition","CWE-59 CWE-59 Improper Link Resolution Before File Access ('Link Following')"],"metrics":[{"version":"4.0","source":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","type":"Secondary","score":"7.3","severity":"HIGH","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","data":{"version":"4.0","vectorString":"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","baseScore":7.3,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"HIGH","attackRequirements":"PRESENT","privilegesRequired":"LOW","userInteraction":"NONE","vulnConfidentialityImpact":"HIGH","vulnIntegrityImpact":"HIGH","vulnAvailabilityImpact":"LOW","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","subAvailabilityImpact":"NONE","exploitMaturity":"NOT_DEFINED","confidentialityRequirement":"NOT_DEFINED","integrityRequirement":"NOT_DEFINED","availabilityRequirement":"NOT_DEFINED","modifiedAttackVector":"NOT_DEFINED","modifiedAttackComplexity":"NOT_DEFINED","modifiedAttackRequirements":"NOT_DEFINED","modifiedPrivilegesRequired":"NOT_DEFINED","modifiedUserInteraction":"NOT_DEFINED","modifiedVulnConfidentialityImpact":"NOT_DEFINED","modifiedVulnIntegrityImpact":"NOT_DEFINED","modifiedVulnAvailabilityImpact":"NOT_DEFINED","modifiedSubConfidentialityImpact":"NOT_DEFINED","modifiedSubIntegrityImpact":"NOT_DEFINED","modifiedSubAvailabilityImpact":"NOT_DEFINED","Safety":"NOT_DEFINED","Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","valueDensity":"NOT_DEFINED","vulnerabilityResponseEffort":"NOT_DEFINED","providerUrgency":"NOT_DEFINED"}},{"version":"4.0","source":"CNA","type":"CVSS","score":"7.3","severity":"HIGH","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","data":{"baseScore":7.3,"baseSeverity":"HIGH","vectorString":"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","version":"4.0"}},{"version":"3.1","source":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","type":"Secondary","score":"6.5","severity":"MEDIUM","vector":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L","baseScore":6.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"HIGH","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"LOW"}},{"version":"3.1","source":"CNA","type":"CVSS","score":"6.5","severity":"MEDIUM","vector":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L","data":{"attackComplexity":"HIGH","attackVector":"LOCAL","availabilityImpact":"LOW","baseScore":6.5,"baseSeverity":"MEDIUM","confidentialityImpact":"HIGH","integrityImpact":"HIGH","privilegesRequired":"LOW","scope":"UNCHANGED","userInteraction":"NONE","vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L","version":"3.1"}}],"references":[{"url":"https://github.com/pgadmin-org/pgadmin4/commit/c4321b9968342716f34bc5f10de6cac3c0567e68","name":"https://github.com/pgadmin-org/pgadmin4/commit/c4321b9968342716f34bc5f10de6cac3c0567e68","refsource":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/pgadmin-org/pgadmin4/commit/730d1e783c339ec696a1f77f2eee6f4b52cb6c37","name":"https://github.com/pgadmin-org/pgadmin4/commit/730d1e783c339ec696a1f77f2eee6f4b52cb6c37","refsource":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/pgadmin-org/pgadmin4/issues/10647","name":"https://github.com/pgadmin-org/pgadmin4/issues/10647","refsource":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/pgadmin-org/pgadmin4/commit/99f5606e2ebc7c94c7acdbab877ce7de54bfc756","name":"https://github.com/pgadmin-org/pgadmin4/commit/99f5606e2ebc7c94c7acdbab877ce7de54bfc756","refsource":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-116250","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-116250","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"pgadmin.org","product":"pgAdmin 4","version":"affected 9.19 custom","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[{"source":"CNA","value":"MUTED CYBERSECURITY S.L. <cybersec@mut3dcybersecurity.com>","lang":"en"},{"source":"CNA","value":"Dave Page <dpage@pgadmin.org>","lang":"en"},{"source":"CNA","value":"Hitesh Jambhale <hitesh.jambhale@enterprisedb.com>","lang":"en"},{"source":"CNA","value":"Hitesh Jambhale <hitesh.jambhale@enterprisedb.com>","lang":"en"},{"source":"CNA","value":"Ashesh Vashi <ashesh.vashi@enterprisedb.com>","lang":"en"}],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"defaultStatus":"unaffected","modules":["File Manager","Import/Export Servers","Backup","Restore","Import/Export Data"],"product":"pgAdmin 4","programFiles":["https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/misc/file_manager/__init__.py","https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/__init__.py","https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/tools/import_export_servers/__init__.py"],"repo":"https://github.com/pgadmin-org/pgadmin4","vendor":"pgadmin.org","versions":[{"lessThan":"9.19","status":"affected","version":"0","versionType":"custom"}]}],"credits":[{"lang":"en","type":"finder","value":"MUTED CYBERSECURITY S.L. <cybersec@mut3dcybersecurity.com>"},{"lang":"en","type":"remediation developer","value":"Dave Page <dpage@pgadmin.org>"},{"lang":"en","type":"remediation developer","value":"Hitesh Jambhale <hitesh.jambhale@enterprisedb.com>"},{"lang":"en","type":"remediation reviewer","value":"Hitesh Jambhale <hitesh.jambhale@enterprisedb.com>"},{"lang":"en","type":"remediation reviewer","value":"Ashesh Vashi <ashesh.vashi@enterprisedb.com>"}],"datePublic":"2026-10-29T00:00:00.000Z","descriptions":[{"lang":"en","value":"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."}],"metrics":[{"cvssV3_1":{"attackComplexity":"HIGH","attackVector":"LOCAL","availabilityImpact":"LOW","baseScore":6.5,"baseSeverity":"MEDIUM","confidentialityImpact":"HIGH","integrityImpact":"HIGH","privilegesRequired":"LOW","scope":"UNCHANGED","userInteraction":"NONE","vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L","version":"3.1"},"format":"CVSS","scenarios":[{"lang":"en","value":"Threat model: an operating-system user other than the pgAdmin service account who can write into a storage directory pgAdmin uses (a shared or network-mounted storage backend), and who also has, or works with, a pgAdmin account using it. An attacker with access to the host as the service account gains nothing from this flaw, so the Attack Vector is Local. Attack Complexity is High: the link must be planted and a race between the check and the open won. Confidentiality and Integrity are High because a file readable or writable by the pgAdmin account can be read (including loaded into a table) or overwritten; Availability is Low for a clobbered file or a hung request. Scope is Unchanged: the operations run with the authority pgAdmin already holds."}]},{"cvssV4_0":{"baseScore":7.3,"baseSeverity":"HIGH","vectorString":"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","version":"4.0"},"format":"CVSS","scenarios":[{"lang":"en","value":"Same reasoning as the CVSS 3.1 entry. AT:P for the race and for the write access to the storage backend obtained outside pgAdmin. VC:H/VI:H/VA:L as above; no subsequent-system impact."}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-367","description":"CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition","lang":"en","type":"CWE"},{"cweId":"CWE-59","description":"CWE-59 Improper Link Resolution Before File Access ('Link Following')","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-30T19:55:18.713Z","orgId":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","shortName":"PostgreSQL"},"references":[{"tags":["issue-tracking"],"url":"https://github.com/pgadmin-org/pgadmin4/issues/10647"},{"tags":["patch"],"url":"https://github.com/pgadmin-org/pgadmin4/commit/99f5606e2ebc7c94c7acdbab877ce7de54bfc756"},{"tags":["patch"],"url":"https://github.com/pgadmin-org/pgadmin4/commit/c4321b9968342716f34bc5f10de6cac3c0567e68"},{"tags":["patch"],"url":"https://github.com/pgadmin-org/pgadmin4/commit/730d1e783c339ec696a1f77f2eee6f4b52cb6c37"}],"source":{"discovery":"EXTERNAL"},"title":"pgAdmin 4: Files opened in a storage directory follow a symbolic link, hard link or FIFO planted after the containment check"}},"cveMetadata":{"assignerOrgId":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","assignerShortName":"PostgreSQL","cveId":"CVE-2026-116250","datePublished":"2026-10-30T19:55:18.713Z","dateReserved":"2026-10-25T16:26:16.420Z","dateUpdated":"2026-10-30T19:55:18.713Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-10-30 20:17:05","lastModifiedDate":"2026-10-30 20:17:05","problem_types":["CWE-59","CWE-367","CWE-367 CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition","CWE-59 CWE-59 Improper Link Resolution Before File Access ('Link Following')"],"metrics":{"cvssMetricV40":[{"source":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","type":"Secondary","cvssData":{"version":"4.0","vectorString":"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","baseScore":7.3,"baseSeverity":"HIGH","attackVector":"LOCAL","attackComplexity":"HIGH","attackRequirements":"PRESENT","privilegesRequired":"LOW","userInteraction":"NONE","vulnConfidentialityImpact":"HIGH","vulnIntegrityImpact":"HIGH","vulnAvailabilityImpact":"LOW","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","subAvailabilityImpact":"NONE","exploitMaturity":"NOT_DEFINED","confidentialityRequirement":"NOT_DEFINED","integrityRequirement":"NOT_DEFINED","availabilityRequirement":"NOT_DEFINED","modifiedAttackVector":"NOT_DEFINED","modifiedAttackComplexity":"NOT_DEFINED","modifiedAttackRequirements":"NOT_DEFINED","modifiedPrivilegesRequired":"NOT_DEFINED","modifiedUserInteraction":"NOT_DEFINED","modifiedVulnConfidentialityImpact":"NOT_DEFINED","modifiedVulnIntegrityImpact":"NOT_DEFINED","modifiedVulnAvailabilityImpact":"NOT_DEFINED","modifiedSubConfidentialityImpact":"NOT_DEFINED","modifiedSubIntegrityImpact":"NOT_DEFINED","modifiedSubAvailabilityImpact":"NOT_DEFINED","Safety":"NOT_DEFINED","Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","valueDensity":"NOT_DEFINED","vulnerabilityResponseEffort":"NOT_DEFINED","providerUrgency":"NOT_DEFINED"}}],"cvssMetricV31":[{"source":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","type":"Secondary","cvssData":{"version":"3.1","vectorString":"CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L","baseScore":6.5,"baseSeverity":"MEDIUM","attackVector":"LOCAL","attackComplexity":"HIGH","privilegesRequired":"LOW","userInteraction":"NONE","scope":"UNCHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"LOW"},"exploitabilityScore":1,"impactScore":5.5}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"116250","Ordinal":"1","Title":"pgAdmin 4: Files opened in a storage directory follow a symbolic","CVE":"CVE-2026-116250","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"116250","Ordinal":"1","NoteData":"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.","Type":"Description","Title":"pgAdmin 4: Files opened in a storage directory follow a symbolic"}]}}}