« Volver al listado

CVE-2026-17351

Estado: AnalizadaCrítica (9.4)—

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.

Leer descripción completaMostrar menos

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.

CVSS

Probabilidad de explotación (EPSS)

EPSS (Exploit Prediction Scoring System, de FIRST) estima la probabilidad de que una vulnerabilidad sea explotada en 30 días. Complementa a CVSS (impacto) y a CISA KEV (explotación confirmada).

🎯 Técnicas ATT&CK

Cómo se explota esta vulnerabilidad y qué consigue el atacante, en el lenguaje de MITRE ATT&CK.

UI:P + acceso a red autenticado (PR:L) con interacción: T1203. Ejecuta SQL arbitrario (CREATE TABLE, COMMIT) mediante inyección en prompt a LLM; impacto primario ejecución de comandos SQL, secundarios modificación de datos y exfiltración.

Inferido por nuestro agente de análisis a partir de la descripción oficial, el vector CVSS y la CWE, y comprobado por un supervisor. Puede contener errores.

🛡️ Mitigaciones ATT&CK que cubren estas técnicas

Restrict Web-Based ContentRestrict File and Directory PermissionsPrivileged Account ManagementRemote Data StorageLimit Software InstallationExecution Prevention

Tecnologías afectadas (1)

Pgadmin — Pgadmin 4

CWE

Referencias

JSON original (NVD)

Mostrar
{
  "id": "CVE-2026-17351",
  "cveTags": [],
  "metrics": {
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-17351",
          "role": "CISA Coordinator",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "total"
            }
          ],
          "version": "2.0.3",
          "timestamp": "2026-07-31T00:00:00+00:00"
        }
      }
    ],
    "cvssMetricV31": [
      {
        "type": "Secondary",
        "source": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "cvssData": {
          "scope": "CHANGED",
          "version": "3.1",
          "baseScore": 9,
          "attackVector": "NETWORK",
          "baseSeverity": "CRITICAL",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H",
          "integrityImpact": "HIGH",
          "userInteraction": "REQUIRED",
          "attackComplexity": "LOW",
          "availabilityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "confidentialityImpact": "HIGH"
        },
        "impactScore": 6,
        "exploitabilityScore": 2.3
      },
      {
        "type": "Primary",
        "source": "nvd@nist.gov",
        "cvssData": {
          "scope": "CHANGED",
          "version": "3.1",
          "baseScore": 9,
          "attackVector": "NETWORK",
          "baseSeverity": "CRITICAL",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H",
          "integrityImpact": "HIGH",
          "userInteraction": "REQUIRED",
          "attackComplexity": "LOW",
          "availabilityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "confidentialityImpact": "HIGH"
        },
        "impactScore": 6,
        "exploitabilityScore": 2.3
      }
    ],
    "cvssMetricV40": [
      {
        "type": "Secondary",
        "source": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "cvssData": {
          "Safety": "NOT_DEFINED",
          "version": "4.0",
          "Recovery": "NOT_DEFINED",
          "baseScore": 9.4,
          "Automatable": "NOT_DEFINED",
          "attackVector": "NETWORK",
          "baseSeverity": "CRITICAL",
          "valueDensity": "NOT_DEFINED",
          "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",
          "exploitMaturity": "NOT_DEFINED",
          "providerUrgency": "NOT_DEFINED",
          "userInteraction": "PASSIVE",
          "attackComplexity": "LOW",
          "attackRequirements": "NONE",
          "privilegesRequired": "LOW",
          "subIntegrityImpact": "HIGH",
          "vulnIntegrityImpact": "HIGH",
          "integrityRequirement": "NOT_DEFINED",
          "modifiedAttackVector": "NOT_DEFINED",
          "subAvailabilityImpact": "HIGH",
          "vulnAvailabilityImpact": "HIGH",
          "availabilityRequirement": "NOT_DEFINED",
          "modifiedUserInteraction": "NOT_DEFINED",
          "modifiedAttackComplexity": "NOT_DEFINED",
          "subConfidentialityImpact": "HIGH",
          "vulnConfidentialityImpact": "HIGH",
          "confidentialityRequirement": "NOT_DEFINED",
          "modifiedAttackRequirements": "NOT_DEFINED",
          "modifiedPrivilegesRequired": "NOT_DEFINED",
          "modifiedSubIntegrityImpact": "NOT_DEFINED",
          "modifiedVulnIntegrityImpact": "NOT_DEFINED",
          "vulnerabilityResponseEffort": "NOT_DEFINED",
          "modifiedSubAvailabilityImpact": "NOT_DEFINED",
          "modifiedVulnAvailabilityImpact": "NOT_DEFINED",
          "modifiedSubConfidentialityImpact": "NOT_DEFINED",
          "modifiedVulnConfidentialityImpact": "NOT_DEFINED"
        }
      }
    ]
  },
  "affected": [
    {
      "source": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
      "affectedData": [
        {
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "modules": [
            "AI Assistant",
            "LLM Tools"
          ],
          "product": "pgAdmin 4",
          "versions": [
            {
              "status": "affected",
              "version": "9.13",
              "lessThan": "9.17",
              "versionType": "custom"
            }
          ],
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/llm/tools/database.py"
          ],
          "defaultStatus": "unaffected"
        }
      ]
    }
  ],
  "published": "2026-07-31T16:16:59.807",
  "references": [
    {
      "url": "https://github.com/pgadmin-org/pgadmin4/commit/bf4792444446f0e7ab721d23cbd6bfe6afaa7a8b",
      "tags": [
        "Patch"
      ],
      "source": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007"
    },
    {
      "url": "https://github.com/pgadmin-org/pgadmin4/commit/ef76102bcd1cdb544eb9b4ef18d3382f22b76752",
      "tags": [
        "Patch"
      ],
      "source": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007"
    },
    {
      "url": "https://github.com/pgadmin-org/pgadmin4/issues/10192",
      "tags": [
        "Issue Tracking",
        "Patch",
        "Vendor Advisory"
      ],
      "source": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007"
    }
  ],
  "vulnStatus": "Analyzed",
  "weaknesses": [
    {
      "type": "Secondary",
      "source": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
      "description": [
        {
          "lang": "en",
          "value": "CWE-89"
        },
        {
          "lang": "en",
          "value": "CWE-115"
        }
      ]
    }
  ],
  "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."
    }
  ],
  "lastModified": "2026-08-05T20:07:14.527",
  "configurations": [
    {
      "nodes": [
        {
          "negate": false,
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:pgadmin:pgadmin_4:*:*:*:*:*:postgresql:*:*",
              "vulnerable": true,
              "matchCriteriaId": "DA305ECD-4B65-4A51-8E65-4C7BD39105F4",
              "versionEndExcluding": "9.17",
              "versionStartIncluding": "9.13"
            }
          ],
          "operator": "OR"
        }
      ]
    }
  ],
  "sourceIdentifier": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007"
}