CVE-2026-116240

{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-116240", "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007", "state": "PUBLISHED", "assignerShortName": "PostgreSQL", "dateReserved": "2026-10-25T16:26:16.419Z", "datePublished": "2026-10-30T19:55:12.603Z", "dateUpdated": "2026-11-06T16:09:09.238Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007", "shortName": "PostgreSQL", "dateUpdated": "2026-10-30T19:55:12.603Z"}, "title": "pgAdmin 4: File Manager and storage-path tools act on a different path from the one checked", "datePublic": "2026-10-29T00:00:00.000Z", "affected": [{"vendor": "pgadmin.org", "product": "pgAdmin 4", "repo": "https://github.com/pgadmin-org/pgadmin4", "modules": ["File Manager", "Import/Export Data", "Backup", "Restore", "Query Tool"], "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"], "versions": [{"status": "affected", "version": "0", "lessThan": "9.19", "versionType": "custom"}], "defaultStatus": "unaffected"}], "descriptions": [{"lang": "en", "value": "In server mode pgAdmin 4 validates a path into the user's storage directory with check_access_permission(), which builds the absolute path with get_abs_path(). Several callers then acted on a path they built differently, so the path checked and the path used could name different files:\n\n- Opening a file in the Query Tool, the Google client secret and, on Windows, Import/Export Data, Backup, Restore and saving a file joined the path to the storage directory after stripping leading slashes and backslashes. On POSIX a path checked as a name inside storage could become an absolute path once stripped, so any file the pgAdmin account can read could be opened; on Windows a path naming a drive discarded the storage directory, so these could read, or write, outside it.\n- Listing a folder decoded the path a second time after the check, so a folder named like an encoded \"..\", which a user can create, listed any directory on the host.\n- Download, delete, rename and the file-exists check appended the path to the storage directory without a separator, so in a deployment where one user's storage directory name is a prefix of another's, another user's files could be read, deleted or moved; download also checked the path appended to itself.\n- Creating a folder could create one in another user's directory.\n\nThe fix makes check_access_permission() return the path it checked and every caller act on that path, decodes folder paths once, and opens, deletes and renames files relative to directories opened from the storage directory without following symbolic links. Desktop mode is not affected.\n\nThis issue affects pgAdmin 4: before 9.19."}], "references": [{"url": "https://github.com/pgadmin-org/pgadmin4/issues/10674", "tags": ["issue-tracking"]}, {"url": "https://github.com/pgadmin-org/pgadmin4/commit/ad6c028cff625a095676065767c7b80219205d28", "tags": ["patch"]}], "metrics": [{"format": "CVSS", "scenarios": [{"lang": "en", "value": "Scored for the worst variant, which needs only an authenticated user in server mode: reading any file the pgAdmin account can read through the Query Tool's file open, and listing any directory. Attack Complexity is Low. Confidentiality is High because that includes pgAdmin's own configuration and database. Integrity is None for this variant; the read, delete and rename of another user's files need a deployment where one user's storage directory name is a prefix of another's, and the write outside storage is limited to Windows server mode. Scope is Unchanged: the access is with the authority of the pgAdmin account."}], "cvssV3_1": {"version": "3.1", "attackVector": "NETWORK", "attackComplexity": "LOW", "privilegesRequired": "LOW", "userInteraction": "NONE", "scope": "UNCHANGED", "confidentialityImpact": "HIGH", "integrityImpact": "NONE", "availabilityImpact": "NONE", "baseSeverity": "MEDIUM", "baseScore": 6.5, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N"}}, {"format": "CVSS", "scenarios": [{"lang": "en", "value": "Same reasoning as the CVSS 3.1 entry. AT:N for the any-file read, which needs no deployment condition. VC:H; no subsequent-system impact is claimed."}], "cvssV4_0": {"version": "4.0", "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N", "baseScore": 7.1, "baseSeverity": "HIGH"}}], "problemTypes": [{"descriptions": [{"lang": "en", "description": "CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')", "cweId": "CWE-22", "type": "CWE"}, {"lang": "en", "description": "CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition", "cweId": "CWE-367", "type": "CWE"}]}], "credits": [{"lang": "en", "value": "Ashesh Vashi <ashesh.vashi@enterprisedb.com>", "type": "remediation developer"}, {"lang": "en", "value": "Hitesh Jambhale <hitesh.jambhale@enterprisedb.com>", "type": "remediation reviewer"}], "source": {"discovery": "INTERNAL"}}, "adp": [{"metrics": [{"other": {"type": "ssvc", "content": {"timestamp": "2026-11-06T16:08:52.136283Z", "id": "CVE-2026-116240", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "role": "CISA Coordinator", "version": "2.0.3"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-11-06T16:09:09.238Z"}}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CISA ADP Vulnrichment", "metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2026-116240", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2026-11-06T16:08:52.136283Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-11-06T16:09:00.667Z"}}], "cna": {"title": "pgAdmin 4: File Manager and storage-path tools act on a different path from the one checked", "source": {"discovery": "INTERNAL"}, "credits": [{"lang": "en", "type": "remediation developer", "value": "Ashesh Vashi <ashesh.vashi@enterprisedb.com>"}, {"lang": "en", "type": "remediation reviewer", "value": "Hitesh Jambhale <hitesh.jambhale@enterprisedb.com>"}], "metrics": [{"format": "CVSS", "cvssV3_1": {"scope": "UNCHANGED", "version": "3.1", "baseScore": 6.5, "attackVector": "NETWORK", "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N", "integrityImpact": "NONE", "userInteraction": "NONE", "attackComplexity": "LOW", "availabilityImpact": "NONE", "privilegesRequired": "LOW", "confidentialityImpact": "HIGH"}, "scenarios": [{"lang": "en", "value": "Scored for the worst variant, which needs only an authenticated user in server mode: reading any file the pgAdmin account can read through the Query Tool's file open, and listing any directory. Attack Complexity is Low. Confidentiality is High because that includes pgAdmin's own configuration and database. Integrity is None for this variant; the read, delete and rename of another user's files need a deployment where one user's storage directory name is a prefix of another's, and the write outside storage is limited to Windows server mode. Scope is Unchanged: the access is with the authority of the pgAdmin account."}]}, {"format": "CVSS", "cvssV4_0": {"version": "4.0", "baseScore": 7.1, "baseSeverity": "HIGH", "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N"}, "scenarios": [{"lang": "en", "value": "Same reasoning as the CVSS 3.1 entry. AT:N for the any-file read, which needs no deployment condition. VC:H; no subsequent-system impact is claimed."}]}], "affected": [{"repo": "https://github.com/pgadmin-org/pgadmin4", "vendor": "pgadmin.org", "modules": ["File Manager", "Import/Export Data", "Backup", "Restore", "Query Tool"], "product": "pgAdmin 4", "versions": [{"status": "affected", "version": "0", "lessThan": "9.19", "versionType": "custom"}], "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"], "defaultStatus": "unaffected"}], "datePublic": "2026-10-29T00:00:00.000Z", "references": [{"url": "https://github.com/pgadmin-org/pgadmin4/issues/10674", "tags": ["issue-tracking"]}, {"url": "https://github.com/pgadmin-org/pgadmin4/commit/ad6c028cff625a095676065767c7b80219205d28", "tags": ["patch"]}], "descriptions": [{"lang": "en", "value": "In server mode pgAdmin 4 validates a path into the user's storage directory with check_access_permission(), which builds the absolute path with get_abs_path(). Several callers then acted on a path they built differently, so the path checked and the path used could name different files:\n\n- Opening a file in the Query Tool, the Google client secret and, on Windows, Import/Export Data, Backup, Restore and saving a file joined the path to the storage directory after stripping leading slashes and backslashes. On POSIX a path checked as a name inside storage could become an absolute path once stripped, so any file the pgAdmin account can read could be opened; on Windows a path naming a drive discarded the storage directory, so these could read, or write, outside it.\n- Listing a folder decoded the path a second time after the check, so a folder named like an encoded \"..\", which a user can create, listed any directory on the host.\n- Download, delete, rename and the file-exists check appended the path to the storage directory without a separator, so in a deployment where one user's storage directory name is a prefix of another's, another user's files could be read, deleted or moved; download also checked the path appended to itself.\n- Creating a folder could create one in another user's directory.\n\nThe fix makes check_access_permission() return the path it checked and every caller act on that path, decodes folder paths once, and opens, deletes and renames files relative to directories opened from the storage directory without following symbolic links. Desktop mode is not affected.\n\nThis issue affects pgAdmin 4: before 9.19."}], "problemTypes": [{"descriptions": [{"lang": "en", "type": "CWE", "cweId": "CWE-22", "description": "CWE-22 Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')"}, {"lang": "en", "type": "CWE", "cweId": "CWE-367", "description": "CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition"}]}], "providerMetadata": {"orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007", "shortName": "PostgreSQL", "dateUpdated": "2026-10-30T19:55:12.603Z"}}}, "cveMetadata": {"cveId": "CVE-2026-116240", "state": "PUBLISHED", "dateUpdated": "2026-11-06T16:09:09.238Z", "dateReserved": "2026-10-25T16:26:16.419Z", "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007", "datePublished": "2026-10-30T19:55:12.603Z", "assignerShortName": "PostgreSQL"}, "dataVersion": "5.2"}

{"affected": [{"affectedData": [{"defaultStatus": "unaffected", "modules": ["File Manager", "Import/Export Data", "Backup", "Restore", "Query Tool"], "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"], "repo": "https://github.com/pgadmin-org/pgadmin4", "vendor": "pgadmin.org", "versions": [{"lessThan": "9.19", "status": "affected", "version": "0", "versionType": "custom"}]}], "source": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007"}], "configurations": [{"nodes": [{"cpeMatch": [{"criteria": "cpe:2.3:a:pgadmin:pgadmin_4:*:*:*:*:*:*:*:*", "matchCriteriaId": "320E46B0-BBE2-47FD-955F-986EC9930403", "versionEndExcluding": "9.19", "vulnerable": true}], "negate": false, "operator": "OR"}]}], "cveTags": [], "descriptions": [{"lang": "en", "value": "In server mode pgAdmin 4 validates a path into the user's storage directory with check_access_permission(), which builds the absolute path with get_abs_path(). Several callers then acted on a path they built differently, so the path checked and the path used could name different files:\n\n- Opening a file in the Query Tool, the Google client secret and, on Windows, Import/Export Data, Backup, Restore and saving a file joined the path to the storage directory after stripping leading slashes and backslashes. On POSIX a path checked as a name inside storage could become an absolute path once stripped, so any file the pgAdmin account can read could be opened; on Windows a path naming a drive discarded the storage directory, so these could read, or write, outside it.\n- Listing a folder decoded the path a second time after the check, so a folder named like an encoded \"..\", which a user can create, listed any directory on the host.\n- Download, delete, rename and the file-exists check appended the path to the storage directory without a separator, so in a deployment where one user's storage directory name is a prefix of another's, another user's files could be read, deleted or moved; download also checked the path appended to itself.\n- Creating a folder could create one in another user's directory.\n\nThe fix makes check_access_permission() return the path it checked and every caller act on that path, decodes folder paths once, and opens, deletes and renames files relative to directories opened from the storage directory without following symbolic links. Desktop mode is not affected.\n\nThis issue affects pgAdmin 4: before 9.19."}], "id": "CVE-2026-116240", "lastModified": "2026-11-06T17:17:14.537", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "NONE", "baseScore": 6.5, "baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N", "version": "3.1"}, "exploitabilityScore": 2.8, "impactScore": 3.6, "source": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007", "type": "Secondary"}, {"cvssData": {"attackComplexity": "LOW", "attackVector": "NETWORK", "availabilityImpact": "NONE", "baseScore": 6.5, "baseSeverity": "MEDIUM", "confidentialityImpact": "HIGH", "integrityImpact": "NONE", "privilegesRequired": "LOW", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N", "version": "3.1"}, "exploitabilityScore": 2.8, "impactScore": 3.6, "source": "nvd@nist.gov", "type": "Primary"}], "cvssMetricV40": [{"cvssData": {"Automatable": "NOT_DEFINED", "Recovery": "NOT_DEFINED", "Safety": "NOT_DEFINED", "attackComplexity": "LOW", "attackRequirements": "NONE", "attackVector": "NETWORK", "availabilityRequirement": "NOT_DEFINED", "baseScore": 7.1, "baseSeverity": "HIGH", "confidentialityRequirement": "NOT_DEFINED", "exploitMaturity": "NOT_DEFINED", "integrityRequirement": "NOT_DEFINED", "modifiedAttackComplexity": "NOT_DEFINED", "modifiedAttackRequirements": "NOT_DEFINED", "modifiedAttackVector": "NOT_DEFINED", "modifiedPrivilegesRequired": "NOT_DEFINED", "modifiedSubAvailabilityImpact": "NOT_DEFINED", "modifiedSubConfidentialityImpact": "NOT_DEFINED", "modifiedSubIntegrityImpact": "NOT_DEFINED", "modifiedUserInteraction": "NOT_DEFINED", "modifiedVulnAvailabilityImpact": "NOT_DEFINED", "modifiedVulnConfidentialityImpact": "NOT_DEFINED", "modifiedVulnIntegrityImpact": "NOT_DEFINED", "privilegesRequired": "LOW", "providerUrgency": "NOT_DEFINED", "subAvailabilityImpact": "NONE", "subConfidentialityImpact": "NONE", "subIntegrityImpact": "NONE", "userInteraction": "NONE", "valueDensity": "NOT_DEFINED", "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/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", "version": "4.0", "vulnAvailabilityImpact": "NONE", "vulnConfidentialityImpact": "HIGH", "vulnIntegrityImpact": "NONE", "vulnerabilityResponseEffort": "NOT_DEFINED"}, "source": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007", "type": "Secondary"}], "ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-116240", "options": [{"exploitation": "none"}, {"automatable": "no"}, {"technicalImpact": "partial"}], "role": "CISA Coordinator", "timestamp": "2026-11-06T16:08:52.136283Z", "version": "2.0.3"}}]}, "published": "2026-10-30T20:17:03.383", "references": [{"source": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007", "tags": ["Patch"], "url": "https://github.com/pgadmin-org/pgadmin4/commit/ad6c028cff625a095676065767c7b80219205d28"}, {"source": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007", "tags": ["Issue Tracking"], "url": "https://github.com/pgadmin-org/pgadmin4/issues/10674"}], "sourceIdentifier": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007", "vulnStatus": "Analyzed", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-22"}, {"lang": "en", "value": "CWE-367"}], "source": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007", "type": "Secondary"}]}

{}

{"affected": [{"configurations": [{"platform": null, "status": "affected", "versions": {"scheme": "generic", "value": "[0,9.19)"}}], "enrichment": {"confidence": 100.0, "confidence_source": "matching", "scores": [{"score": 100.0, "source": "matching"}]}, "original": {"product": "pgAdmin 4", "source": "cna", "vendor": "pgadmin.org"}, "product": "pgadmin_4", "vendor": "pgadmin"}], "created": "2026-10-30T21:45:14.729635+00:00", "updated": "2026-10-30T22:00:15.618460+00:00", "vendors": ["pgadmin", "pgadmin$PRODUCT$pgadmin_4"]}