{
  "affected": [
    {
      "ranges": [
        {
          "database_specific": {
            "cpe": "cpe:2.3:a:pgadmin:pgadmin_4:*:*:*:*:*:postgresql:*:*",
            "extracted_events": [
              {
                "introduced": "1.0"
              },
              {
                "fixed": "9.16"
              }
            ],
            "source": [
              "CPE_RANGE",
              "REFERENCES"
            ]
          },
          "events": [
            {
              "introduced": "30397476da45e419a409710e7447bf0f10fcbcd9"
            },
            {
              "fixed": "888a053231923e6704b56165cf248db056252144"
            },
            {
              "fixed": "2ae0d3610"
            },
            {
              "fixed": "658bb585d"
            }
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "type": "GIT"
        }
      ]
    }
  ],
  "database_specific": {
    "cna_assigner": "PostgreSQL",
    "cwe_ids": [
      "CWE-116",
      "CWE-89"
    ],
    "osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/12xxx/CVE-2026-12044.json"
  },
  "details": "SQL injection in pgAdmin 4 across every dialog template that renders ``COMMENT ON ... IS '\u003cdescription\u003e'`` for a user-supplied description field. The Jinja templates for Domains (and their constraints), Foreign Tables, Languages, and Event Triggers, plus the Views OID-lookup query, interpolated the description directly inside a single-quoted SQL literal -- ``'{{ data.description }}'`` -- instead of passing it through the ``qtLiteral`` escape filter. An authenticated pgAdmin user with permission to create or alter the affected object types could submit a description containing an apostrophe, break out of the literal and chain arbitrary SQL. The injected SQL runs under the PostgreSQL role the user is already authenticated as; for a connected role with ``COPY ... TO/FROM PROGRAM`` (typically PostgreSQL superuser), this chains to OS command execution on the PostgreSQL host. The defect does not cross a privilege boundary -- the user already has direct SQL access to that role through pgAdmin's Query Tool -- so the attacker gains no capability beyond what their database role already grants. The marginal impact captures bypass of any application-layer Query Tool gating an operator may have configured.\n\nThe defect was originally reported against the Domain Dialog ``description`` field; a code-wide audit identified sixteen sites of the same pattern across the templates listed above. The same review also surfaced ten related sinks in the pgstattuple/pgstatindex stats templates -- ``pgstattuple('{{schema}}.{{table}}')`` and the matching pgstatindex shape -- where ``qtIdent`` escapes embedded double quotes inside the identifier but not apostrophes, so a user with CREATE privilege on a schema could plant a table or index named ``foo'bar`` and a later stats viewer would render an unbalanced literal.\n\nFix is layered:\n\n  1. Sites: replace every ``'{{ x.description }}'`` with ``{{ x.description|qtLiteral(conn) }}`` (no surrounding quotes -- the filter wraps the value in escaped quotes itself). Plumb ``conn=self.conn`` through every ``render_template`` call that loads one of these templates. Also corrects a ``{ % elif`` Jinja typo in the foreign-table schema diff (dead branch). Rewrite the ten pgstattuple/pgstatindex stats sites to address the relation via OID + ``::oid::regclass`` cast (e.g. ``pgstattuple({{ tid }}::oid::regclass)``), eliminating the embedded literal-call form entirely so that bug-class can no longer recur there.\n\n  2. Driver hardening: ``qtLiteral`` (in ``utils/driver/psycopg3/__init__.py``) used to silently return the raw unescaped value when its ``conn`` argument was falsy. It now raises ``ValueError`` -- surfacing the entire bug class going forward. The change immediately uncovered eight latent plumbing bugs (in ``schemas/__init__.py``, ``schemas/functions/__init__.py``, ``schemas/tables/utils.py``, ``foreign_servers/__init__.py``, and seven sites in ``roles/__init__.py``) -- all fixed as part of this patch. The inner ``except`` block that swallowed adapter-level failures and returned the raw value is also removed, so unadaptable inputs raise instead of leaking unescaped values.\n\n  3. Regression tests: a per-template behavioural test renders each previously-vulnerable template with an apostrophe-injection payload and asserts the escaped fragment is present and the vulnerable fragment absent; a lint test walks every ``*.sql`` template flagging any ``'{{ ... }}'`` single-quote-wrapped interpolation against an explicit allowlist; unit tests cover the new qtLiteral fail-fast and inner-except raise paths.\n\nThis issue affects pgAdmin 4: from 1.0 before 9.16.",
  "id": "CVE-2026-12044",
  "modified": "2026-07-15T01:48:51.270007704Z",
  "published": "2026-06-18T23:37:16.202Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/12xxx/CVE-2026-12044.json"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-12044"
    },
    {
      "type": "REPORT",
      "url": "https://github.com/pgadmin-org/pgadmin4/issues/10078"
    },
    {
      "type": "FIX",
      "url": "https://github.com/pgadmin-org/pgadmin4/commit/2ae0d3610"
    },
    {
      "type": "FIX",
      "url": "https://github.com/pgadmin-org/pgadmin4/commit/658bb585d"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/pgadmin-org/pgadmin4"
    }
  ],
  "schema_version": "1.8.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "pgAdmin 4: SQL injection in COMMENT ON ... IS '\u003cdescription\u003e' rendering across dialog templates"
}