CVE-2026-17351
Full vulnerability record from the local CVENow database.
Description
The fix for CVE-2026-12045 in pgAdmin 4 9.16 required the LLM-supplied query passed to the AI Assistant's execute_sql_query tool to parse, via sqlparse, as exactly one non-transaction-control statement before running it inside a BEGIN TRANSACTION READ ONLY wrapper. sqlparse's string-literal lexing can disagree with PostgreSQL's own parser: under standard_conforming_strings = on (PostgreSQL's default since 9.1), a backslash immediately before a quote is an ordinary character to PostgreSQL, but sqlparse treats it as escaping the quote. A payload such as SELECT '\';COMMIT;CREATE TABLE pwn(x int);SELECT 1 --' therefore parses as a single SELECT to sqlparse's validator, while PostgreSQL executes it as four statements: the smuggled COMMIT ends the wrapping read-only transaction, and the trailing ROLLBACK becomes a no-op. This reintroduces the same write/RCE bypass CVE-2026-12045 was meant to close, reachable via the same indirect prompt-injection delivery (an attacker plants the payload in any object the AI Assistant may read; the LLM emits it as a tool call). An initial candidate fix ran the query with psycopg's execute(..., prepare=True), intending to force PostgreSQL's own Parse step (extended query protocol) to reject multi-statement text regardless of sqlparse's classification. This candidate fix does not work as submitted: psycopg3's PrepareManager silently ignores the prepare argument whenever the connection's prepare_threshold is None, which is pgAdmin's default for every server connection (the per-server "Prepare threshold" field is blank unless an administrator explicitly sets it) -- psycopg3 falls back to the simple query protocol, the same multi-statement-capable path the bypass exploits, so the candidate fix closes nothing on any real-world default configuration. The corrected fix sets conn.prepare_threshold = 0 directly on the dedicated, single-use read-only connection the AI Assistant tool opens, structurally forcing the extended query protocol independent of any server-level configuration. Verified against a live PostgreSQL 18 instance: the payload executes successfully under the prepare_threshold=None (default) behavior, and is rejected with "cannot insert multiple commands into a prepared statement" once prepare_threshold=0 is set on that connection. This issue affects pgAdmin 4: from 9.13 before 9.17.
View original CVE JSON
{
"id": "CVE-2026-17351",
"sourceIdentifier": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
"published": "2026-07-31T16:16:59.807",
"lastModified": "2026-10-23T23:10:00.157",
"vulnStatus": "Analyzed",
"cveTags": [],
"descriptions": [
{
"lang": "en",
"value": "The fix for CVE-2026-12045 in pgAdmin 4 9.16 required the LLM-supplied query passed to the AI Assistant's execute_sql_query tool to parse, via sqlparse, as exactly one non-transaction-control statement before running it inside a BEGIN TRANSACTION READ ONLY wrapper. sqlparse's string-literal lexing can disagree with PostgreSQL's own parser: under standard_conforming_strings = on (PostgreSQL's default since 9.1), a backslash immediately before a quote is an ordinary character to PostgreSQL, but sqlparse treats it as escaping the quote. A payload such as SELECT '\\';COMMIT;CREATE TABLE pwn(x int);SELECT 1 --' therefore parses as a single SELECT to sqlparse's validator, while PostgreSQL executes it as four statements: the smuggled COMMIT ends the wrapping read-only transaction, and the trailing ROLLBACK becomes a no-op. This reintroduces the same write/RCE bypass CVE-2026-12045 was meant to close, reachable via the same indirect prompt-injection delivery (an attacker plants the payload in any object the AI Assistant may read; the LLM emits it as a tool call).\n\nAn initial candidate fix ran the query with psycopg's execute(..., prepare=True), intending to force PostgreSQL's own Parse step (extended query protocol) to reject multi-statement text regardless of sqlparse's classification. This candidate fix does not work as submitted: psycopg3's PrepareManager silently ignores the prepare argument whenever the connection's prepare_threshold is None, which is pgAdmin's default for every server connection (the per-server \"Prepare threshold\" field is blank unless an administrator explicitly sets it) -- psycopg3 falls back to the simple query protocol, the same multi-statement-capable path the bypass exploits, so the candidate fix closes nothing on any real-world default configuration.\n\nThe corrected fix sets conn.prepare_threshold = 0 directly on the dedicated, single-use read-only connection the AI Assistant tool opens, structurally forcing the extended query protocol independent of any server-level configuration. Verified against a live PostgreSQL 18 instance: the payload executes successfully under the prepare_threshold=None (default) behavior, and is rejected with \"cannot insert multiple commands into a prepared statement\" once prepare_threshold=0 is set on that connection.\n\nThis issue affects pgAdmin 4: from 9.13 before 9.17."
},
{
"lang": "es",
"value": "La solución para CVE-2026-12045 en pgAdmin 4 9.16 requería que la consulta proporcionada por el LLM, pasada a la herramienta execute_sql_query del Asistente de IA, se analizara, a través de sqlparse, como exactamente una declaración que no fuera de control de transacciones antes de ejecutarla dentro de un envoltorio BEGIN TRANSACTION READ ONLY. El análisis léxico de literales de cadena de sqlparse puede diferir del propio analizador de PostgreSQL: bajo standard_conforming_strings = on (el valor predeterminado de PostgreSQL desde la versión 9.1), una barra invertida inmediatamente antes de una comilla es un carácter ordinario para PostgreSQL, pero sqlparse la trata como un escape de la comilla. Una carga útil como SELECT ’\\’;COMMIT;CREATE TABLE pwn(x int);SELECT 1 --’ por lo tanto, se analiza como un único SELECT para el validador de sqlparse, mientras que PostgreSQL la ejecuta como cuatro declaraciones: el COMMIT introducido de contrabando finaliza la transacción de solo lectura envolvente, y el ROLLBACK final se convierte en una operación nula. Esto reintroduce el mismo bypass de escritura/RCE que CVE-2026-12045 pretendía cerrar, alcanzable a través de la misma entrega indirecta de inyección de prompt (un atacante planta la carga útil en cualquier objeto que el Asistente de IA pueda leer; el LLM la emite como una llamada a herramienta).\n\nUna solución candidata inicial ejecutó la consulta con execute(..., prepare=True) de psycopg, con la intención de forzar el propio paso de Parse de PostgreSQL (protocolo de consulta extendido) para rechazar texto con múltiples declaraciones independientemente de la clasificación de sqlparse. Esta solución candidata no funciona como se envió: el PrepareManager de psycopg3 ignora silenciosamente el argumento prepare siempre que el prepare_threshold de la conexión es None, que es el valor predeterminado de pgAdmin para cada conexión de servidor (el campo ’Umbral de preparación’ por servidor está en blanco a menos que un administrador lo configure explícitamente) -- psycopg3 recurre al protocolo de consulta simple, la misma ruta capaz de múltiples declaraciones que explota el bypass, por lo que la solución candidata no cierra nada en ninguna configuración predeterminada del mundo real.\n\nLa solución corregida establece conn.prepare_threshold = 0 directamente en la conexión de solo lectura dedicada y de un solo uso que abre la herramienta del Asistente de IA, forzando estructuralmente el protocolo de consulta extendido independientemente de cualquier configuración a nivel de servidor. Verificado contra una instancia activa de PostgreSQL 18: la carga útil se ejecuta correctamente bajo el comportamiento prepare_threshold=None (predeterminado), y es rechazada con ’cannot insert multiple commands into a prepared statement’ una vez que prepare_threshold=0 se establece en esa conexión.\n\nEste problema afecta a pgAdmin 4: desde la versión 9.13 hasta antes de la 9.17."
}
],
"affected": [
{
"source": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
"affectedData": [
{
"vendor": "pgadmin.org",
"product": "pgAdmin 4",
"defaultStatus": "unaffected",
"modules": [
"AI Assistant",
"LLM Tools"
],
"programFiles": [
"https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/llm/tools/database.py"
],
"repo": "https://github.com/pgadmin-org/pgadmin4",
"versions": [
{
"version": "9.13",
"lessThan": "9.17",
"versionType": "custom",
"status": "affected"
}
]
}
]
}
],
"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:P/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": "PASSIVE",
"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:R/S:C/C:H/I:H/A:H",
"baseScore": 9.0,
"baseSeverity": "CRITICAL",
"attackVector": "NETWORK",
"attackComplexity": "LOW",
"privilegesRequired": "LOW",
"userInteraction": "REQUIRED",
"scope": "CHANGED",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"availabilityImpact": "HIGH"
},
"exploitabilityScore": 2.3,
"impactScore": 6.0
},
{
"source": "[email protected]",
"type": "Primary",
"cvssData": {
"version": "3.1",
"vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H",
"baseScore": 9.0,
"baseSeverity": "CRITICAL",
"attackVector": "NETWORK",
"attackComplexity": "LOW",
"privilegesRequired": "LOW",
"userInteraction": "REQUIRED",
"scope": "CHANGED",
"confidentialityImpact": "HIGH",
"integrityImpact": "HIGH",
"availabilityImpact": "HIGH"
},
"exploitabilityScore": 2.3,
"impactScore": 6.0
}
],
"ssvcV203": [
{
"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
"ssvcData": {
"timestamp": "2026-07-31T00:00:00+00:00",
"id": "CVE-2026-17351",
"options": [
{
"exploitation": "none"
},
{
"automatable": "no"
},
{
"technicalImpact": "total"
}
],
"role": "CISA Coordinator",
"version": "2.0.3"
}
}
]
},
"weaknesses": [
{
"source": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
"type": "Secondary",
"description": [
{
"lang": "en",
"value": "CWE-89"
},
{
"lang": "en",
"value": "CWE-115"
}
]
}
],
"configurations": [
{
"nodes": [
{
"operator": "OR",
"negate": false,
"cpeMatch": [
{
"vulnerable": true,
"criteria": "cpe:2.3:a:pgadmin:pgadmin_4:*:*:*:*:*:postgresql:*:*",
"versionStartIncluding": "9.13",
"versionEndExcluding": "9.17",
"matchCriteriaId": "DA305ECD-4B65-4A51-8E65-4C7BD39105F4"
}
]
}
]
}
],
"references": [
{
"url": "https://github.com/pgadmin-org/pgadmin4/commit/bf4792444446f0e7ab721d23cbd6bfe6afaa7a8b",
"source": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
"tags": [
"Patch"
]
},
{
"url": "https://github.com/pgadmin-org/pgadmin4/commit/ef76102bcd1cdb544eb9b4ef18d3382f22b76752",
"source": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
"tags": [
"Patch"
]
},
{
"url": "https://github.com/pgadmin-org/pgadmin4/issues/10192",
"source": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
"tags": [
"Issue Tracking",
"Patch",
"Vendor Advisory"
]
}
]
}