{"api_version":"1","generated_at":"2026-07-31T20:51:26+00:00","cve":"CVE-2026-17566","urls":{"html":"https://cve.report/CVE-2026-17566","api":"https://cve.report/api/cve/CVE-2026-17566.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-17566","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-17566"},"summary":{"title":"pgAdmin 4: RCE via backslash-escape mismatch in Import/Export Data query guard (incomplete defense, sibling gap to CVE-2025-13780)","description":"pgAdmin 4's Import/Export Data tool builds a psql \\copy (...) command line by interpolating a user-supplied SQL query into a Jinja template and passing the rendered line to psql via --command. To stop an attacker from breaking out of the (...) wrapper, create_import_export_job() (route POST /import_export/job/<sid>, gated only by the ordinary, commonly-granted tools_import_export_data permission) validated the query with a hand-written parenthesis-balance checker, _is_query_parens_balanced(). That checker always treated a backslash before a single quote (\\') as escaping the quote, i.e. as if standard_conforming_strings were off. PostgreSQL has defaulted standard_conforming_strings to on since 9.1 (2010), the default on every PostgreSQL version pgAdmin 4 currently supports (13-18); under that default psql's own \\copy tokenizer treats \\ as an ordinary character, so a single quote immediately after it closes the string literal. A query such as SELECT 'a\\') TO PROGRAM 'echo pwned' x' was therefore accepted as \"balanced\" by pgAdmin's checker (which believed the ) was still inside the string), while psql, run through the actual rendered command line, closes the string at that point and treats the following ) as the end of the wrapping \\copy (...) subquery, exposing an attacker-chosen TO PROGRAM '<command>' clause that psql executes via popen() -- independent of a subsequent syntax error later on the same line. This is the same class of bug as CVE-2025-12762/CVE-2025-13780 (RCE via psql meta-command/COPY injection during PLAIN-format dump restore), reached through an independently written defense in a different module (Import/Export Data rather than Restore) that had its own, different logic bug (inverted backslash-escape semantics rather than a BOM-defeated regex anchor).\n\nThe fix rejects any backslash inside a single-quoted string in the query outright, rather than picking one of the two possible psql interpretations. This is intentionally conservative: because the correct interpretation of \\ depends on the target server's standard_conforming_strings setting, which the checker cannot reliably know at validation time, refusing the query is safer than guessing.\n\nThis issue affects pgAdmin 4: from the introduction of _is_query_parens_balanced() before 9.18.","state":"PUBLISHED","assigner":"PostgreSQL","published_at":"2026-07-31 16:17:00","updated_at":"2026-07-31 18:17:11"},"problem_types":["CWE-78","CWE-115","CWE-78 CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","CWE-115 CWE-115 Misinterpretation of Input"],"metrics":[{"version":"4.0","source":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","type":"Secondary","score":"9.4","severity":"CRITICAL","vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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":9.4,"baseSeverity":"CRITICAL","attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"NONE","privilegesRequired":"LOW","userInteraction":"NONE","vulnConfidentialityImpact":"HIGH","vulnIntegrityImpact":"HIGH","vulnAvailabilityImpact":"HIGH","subConfidentialityImpact":"HIGH","subIntegrityImpact":"HIGH","subAvailabilityImpact":"HIGH","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":"9.4","severity":"CRITICAL","vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H","data":{"baseScore":9.4,"baseSeverity":"CRITICAL","vectorString":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H","version":"4.0"}},{"version":"3.1","source":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","type":"Secondary","score":"9.9","severity":"CRITICAL","vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","data":{"version":"3.1","vectorString":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","baseScore":9.9,"baseSeverity":"CRITICAL","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"CHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"}},{"version":"3.1","source":"CNA","type":"CVSS","score":"9.9","severity":"CRITICAL","vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","data":{"attackComplexity":"LOW","attackVector":"NETWORK","availabilityImpact":"HIGH","baseScore":9.9,"baseSeverity":"CRITICAL","confidentialityImpact":"HIGH","integrityImpact":"HIGH","privilegesRequired":"LOW","scope":"CHANGED","userInteraction":"NONE","vectorString":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","version":"3.1"}}],"references":[{"url":"https://github.com/pgadmin-org/pgadmin4/commit/1496fabe28c9f825f6bac0f0d000d9d3276322c3","name":"https://github.com/pgadmin-org/pgadmin4/commit/1496fabe28c9f825f6bac0f0d000d9d3276322c3","refsource":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/pgadmin-org/pgadmin4/issues/10213","name":"https://github.com/pgadmin-org/pgadmin4/issues/10213","refsource":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-17566","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-17566","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"pgadmin.org","product":"pgAdmin 4","version":"affected 9.18 custom","platforms":[]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[{"source":"CNA","value":"Arpit Jain (arpitjain099)","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":{"adp":[{"metrics":[{"other":{"content":{"id":"CVE-2026-17566","options":[{"Exploitation":"none"},{"Automatable":"no"},{"Technical Impact":"total"}],"role":"CISA Coordinator","timestamp":"2026-07-31T16:58:55.142206Z","version":"2.0.3"},"type":"ssvc"}}],"providerMetadata":{"dateUpdated":"2026-07-31T16:59:40.943Z","orgId":"134c704f-9b21-4f2e-91b3-4a467353bcc0","shortName":"CISA-ADP"},"title":"CISA ADP Vulnrichment"}],"cna":{"affected":[{"defaultStatus":"unaffected","modules":["Import/Export Data"],"product":"pgAdmin 4","programFiles":["https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/tools/import_export/__init__.py"],"repo":"https://github.com/pgadmin-org/pgadmin4","vendor":"pgadmin.org","versions":[{"lessThan":"9.18","status":"affected","version":"0","versionType":"custom"}]}],"credits":[{"lang":"en","type":"finder","value":"Arpit Jain (arpitjain099)"},{"lang":"en","type":"remediation developer","value":"Ashesh Vashi <ashesh.vashi@enterprisedb.com>"}],"descriptions":[{"lang":"en","value":"pgAdmin 4's Import/Export Data tool builds a psql \\copy (...) command line by interpolating a user-supplied SQL query into a Jinja template and passing the rendered line to psql via --command. To stop an attacker from breaking out of the (...) wrapper, create_import_export_job() (route POST /import_export/job/<sid>, gated only by the ordinary, commonly-granted tools_import_export_data permission) validated the query with a hand-written parenthesis-balance checker, _is_query_parens_balanced(). That checker always treated a backslash before a single quote (\\') as escaping the quote, i.e. as if standard_conforming_strings were off. PostgreSQL has defaulted standard_conforming_strings to on since 9.1 (2010), the default on every PostgreSQL version pgAdmin 4 currently supports (13-18); under that default psql's own \\copy tokenizer treats \\ as an ordinary character, so a single quote immediately after it closes the string literal. A query such as SELECT 'a\\') TO PROGRAM 'echo pwned' x' was therefore accepted as \"balanced\" by pgAdmin's checker (which believed the ) was still inside the string), while psql, run through the actual rendered command line, closes the string at that point and treats the following ) as the end of the wrapping \\copy (...) subquery, exposing an attacker-chosen TO PROGRAM '<command>' clause that psql executes via popen() -- independent of a subsequent syntax error later on the same line. This is the same class of bug as CVE-2025-12762/CVE-2025-13780 (RCE via psql meta-command/COPY injection during PLAIN-format dump restore), reached through an independently written defense in a different module (Import/Export Data rather than Restore) that had its own, different logic bug (inverted backslash-escape semantics rather than a BOM-defeated regex anchor).\n\nThe fix rejects any backslash inside a single-quoted string in the query outright, rather than picking one of the two possible psql interpretations. This is intentionally conservative: because the correct interpretation of \\ depends on the target server's standard_conforming_strings setting, which the checker cannot reliably know at validation time, refusing the query is safer than guessing.\n\nThis issue affects pgAdmin 4: from the introduction of _is_query_parens_balanced() before 9.18."}],"metrics":[{"cvssV3_1":{"attackComplexity":"LOW","attackVector":"NETWORK","availabilityImpact":"HIGH","baseScore":9.9,"baseSeverity":"CRITICAL","confidentialityImpact":"HIGH","integrityImpact":"HIGH","privilegesRequired":"LOW","scope":"CHANGED","userInteraction":"NONE","vectorString":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","version":"3.1"},"format":"CVSS","scenarios":[{"lang":"en","value":"Threat model: same as CVE-2025-12762/13780. An authenticated pgAdmin user (server mode) holding only the ordinary, routinely-granted \"Import/Export Data\" tool permission (tools_import_export_data) -- not an admin-only permission -- submits a single crafted POST to /import_export/job/<sid> with is_query_export true and a query field containing the payload. No further user interaction, no special server-side configuration, and no elevated pgAdmin role is required. Successful exploitation runs an arbitrary OS command as the pgAdmin application server's service account, which is a privilege escalation beyond anything the Import/Export Data permission is meant to grant (database-query access, not host command execution) -- Scope Changed. Impact is full compromise of the pgAdmin host (C/I/A: High)."}]},{"cvssV4_0":{"baseScore":9.4,"baseSeverity":"CRITICAL","vectorString":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H","version":"4.0"},"format":"CVSS","scenarios":[{"lang":"en","value":"Same reasoning as the CVSS 3.1 entry: network-reachable, low privilege required, no user interaction, host RCE compromises both pgAdmin's own authority (SC/SI/SA: High) and the underlying system data/integrity/availability (VC/VI/VA: High)."}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-78","description":"CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","lang":"en","type":"CWE"},{"cweId":"CWE-115","description":"CWE-115 Misinterpretation of Input","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-07-31T16:00:22.738Z","orgId":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","shortName":"PostgreSQL"},"references":[{"tags":["issue-tracking"],"url":"https://github.com/pgadmin-org/pgadmin4/issues/10213"},{"tags":["patch"],"url":"https://github.com/pgadmin-org/pgadmin4/commit/1496fabe28c9f825f6bac0f0d000d9d3276322c3"}],"source":{"discovery":"EXTERNAL"},"title":"pgAdmin 4: RCE via backslash-escape mismatch in Import/Export Data query guard (incomplete defense, sibling gap to CVE-2025-13780)"}},"cveMetadata":{"assignerOrgId":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","assignerShortName":"PostgreSQL","cveId":"CVE-2026-17566","datePublished":"2026-07-31T16:00:22.738Z","dateReserved":"2026-07-27T14:43:12.802Z","dateUpdated":"2026-07-31T16:59:40.943Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-07-31 16:17:00","lastModifiedDate":"2026-07-31 18:17:11","problem_types":["CWE-78","CWE-115","CWE-78 CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')","CWE-115 CWE-115 Misinterpretation of Input"],"metrics":{"cvssMetricV40":[{"source":"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007","type":"Secondary","cvssData":{"version":"4.0","vectorString":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/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":9.4,"baseSeverity":"CRITICAL","attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"NONE","privilegesRequired":"LOW","userInteraction":"NONE","vulnConfidentialityImpact":"HIGH","vulnIntegrityImpact":"HIGH","vulnAvailabilityImpact":"HIGH","subConfidentialityImpact":"HIGH","subIntegrityImpact":"HIGH","subAvailabilityImpact":"HIGH","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:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H","baseScore":9.9,"baseSeverity":"CRITICAL","attackVector":"NETWORK","attackComplexity":"LOW","privilegesRequired":"LOW","userInteraction":"NONE","scope":"CHANGED","confidentialityImpact":"HIGH","integrityImpact":"HIGH","availabilityImpact":"HIGH"},"exploitabilityScore":3.1,"impactScore":6}],"ssvcV203":[{"source":"134c704f-9b21-4f2e-91b3-4a467353bcc0","ssvcData":{"timestamp":"2026-07-31T16:58:55.142206Z","id":"CVE-2026-17566","options":[{"exploitation":"none"},{"automatable":"no"},{"technicalImpact":"total"}],"role":"CISA Coordinator","version":"2.0.3"}}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"17566","Ordinal":"1","Title":"pgAdmin 4: RCE via backslash-escape mismatch in Import/Export Da","CVE":"CVE-2026-17566","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"17566","Ordinal":"1","NoteData":"pgAdmin 4's Import/Export Data tool builds a psql \\copy (...) command line by interpolating a user-supplied SQL query into a Jinja template and passing the rendered line to psql via --command. To stop an attacker from breaking out of the (...) wrapper, create_import_export_job() (route POST /import_export/job/<sid>, gated only by the ordinary, commonly-granted tools_import_export_data permission) validated the query with a hand-written parenthesis-balance checker, _is_query_parens_balanced(). That checker always treated a backslash before a single quote (\\') as escaping the quote, i.e. as if standard_conforming_strings were off. PostgreSQL has defaulted standard_conforming_strings to on since 9.1 (2010), the default on every PostgreSQL version pgAdmin 4 currently supports (13-18); under that default psql's own \\copy tokenizer treats \\ as an ordinary character, so a single quote immediately after it closes the string literal. A query such as SELECT 'a\\') TO PROGRAM 'echo pwned' x' was therefore accepted as \"balanced\" by pgAdmin's checker (which believed the ) was still inside the string), while psql, run through the actual rendered command line, closes the string at that point and treats the following ) as the end of the wrapping \\copy (...) subquery, exposing an attacker-chosen TO PROGRAM '<command>' clause that psql executes via popen() -- independent of a subsequent syntax error later on the same line. This is the same class of bug as CVE-2025-12762/CVE-2025-13780 (RCE via psql meta-command/COPY injection during PLAIN-format dump restore), reached through an independently written defense in a different module (Import/Export Data rather than Restore) that had its own, different logic bug (inverted backslash-escape semantics rather than a BOM-defeated regex anchor).\n\nThe fix rejects any backslash inside a single-quoted string in the query outright, rather than picking one of the two possible psql interpretations. This is intentionally conservative: because the correct interpretation of \\ depends on the target server's standard_conforming_strings setting, which the checker cannot reliably know at validation time, refusing the query is safer than guessing.\n\nThis issue affects pgAdmin 4: from the introduction of _is_query_parens_balanced() before 9.18.","Type":"Description","Title":"pgAdmin 4: RCE via backslash-escape mismatch in Import/Export Da"}]}}}