Vulnerability Details CVE-2026-12044
SQL injection in pgAdmin 4 across every dialog template that renders ``COMMENT ON ... IS '<description>'`` 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.
The 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.
Fix is layered:
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.
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.
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.
This issue affects pgAdmin 4: from 1.0 before 9.16.
Exploit prediction scoring system (EPSS) score
EPSS Score 0.005
EPSS Ranking 39.9%
CVSS Severity
CVSS v3 Score 8.8
Products affected by CVE-2026-12044
-
cpe:2.3:a:pgadmin:pgadmin_4:1.0
-
cpe:2.3:a:pgadmin:pgadmin_4:1.1
-
cpe:2.3:a:pgadmin:pgadmin_4:1.2
-
cpe:2.3:a:pgadmin:pgadmin_4:1.3
-
cpe:2.3:a:pgadmin:pgadmin_4:1.4
-
cpe:2.3:a:pgadmin:pgadmin_4:1.5
-
cpe:2.3:a:pgadmin:pgadmin_4:1.6
-
cpe:2.3:a:pgadmin:pgadmin_4:2.0
-
cpe:2.3:a:pgadmin:pgadmin_4:2.1
-
cpe:2.3:a:pgadmin:pgadmin_4:3.0
-
cpe:2.3:a:pgadmin:pgadmin_4:3.1
-
cpe:2.3:a:pgadmin:pgadmin_4:3.2
-
cpe:2.3:a:pgadmin:pgadmin_4:3.3
-
cpe:2.3:a:pgadmin:pgadmin_4:3.4
-
cpe:2.3:a:pgadmin:pgadmin_4:3.5
-
cpe:2.3:a:pgadmin:pgadmin_4:3.6
-
cpe:2.3:a:pgadmin:pgadmin_4:4.0
-
cpe:2.3:a:pgadmin:pgadmin_4:4.1
-
cpe:2.3:a:pgadmin:pgadmin_4:4.10
-
cpe:2.3:a:pgadmin:pgadmin_4:4.11
-
cpe:2.3:a:pgadmin:pgadmin_4:4.12
-
cpe:2.3:a:pgadmin:pgadmin_4:4.13
-
cpe:2.3:a:pgadmin:pgadmin_4:4.14
-
cpe:2.3:a:pgadmin:pgadmin_4:4.15
-
cpe:2.3:a:pgadmin:pgadmin_4:4.16
-
cpe:2.3:a:pgadmin:pgadmin_4:4.17
-
cpe:2.3:a:pgadmin:pgadmin_4:4.18
-
cpe:2.3:a:pgadmin:pgadmin_4:4.19
-
cpe:2.3:a:pgadmin:pgadmin_4:4.2
-
cpe:2.3:a:pgadmin:pgadmin_4:4.20
-
cpe:2.3:a:pgadmin:pgadmin_4:4.21
-
cpe:2.3:a:pgadmin:pgadmin_4:4.22
-
cpe:2.3:a:pgadmin:pgadmin_4:4.23
-
cpe:2.3:a:pgadmin:pgadmin_4:4.24
-
cpe:2.3:a:pgadmin:pgadmin_4:4.25
-
cpe:2.3:a:pgadmin:pgadmin_4:4.26
-
cpe:2.3:a:pgadmin:pgadmin_4:4.27
-
cpe:2.3:a:pgadmin:pgadmin_4:4.28
-
cpe:2.3:a:pgadmin:pgadmin_4:4.29
-
cpe:2.3:a:pgadmin:pgadmin_4:4.3
-
cpe:2.3:a:pgadmin:pgadmin_4:4.30
-
cpe:2.3:a:pgadmin:pgadmin_4:4.4
-
cpe:2.3:a:pgadmin:pgadmin_4:4.5
-
cpe:2.3:a:pgadmin:pgadmin_4:4.6
-
cpe:2.3:a:pgadmin:pgadmin_4:4.7
-
cpe:2.3:a:pgadmin:pgadmin_4:4.8
-
cpe:2.3:a:pgadmin:pgadmin_4:4.9
-
cpe:2.3:a:pgadmin:pgadmin_4:5.0
-
cpe:2.3:a:pgadmin:pgadmin_4:5.1
-
cpe:2.3:a:pgadmin:pgadmin_4:5.2
-
cpe:2.3:a:pgadmin:pgadmin_4:5.3
-
cpe:2.3:a:pgadmin:pgadmin_4:5.4
-
cpe:2.3:a:pgadmin:pgadmin_4:5.5
-
cpe:2.3:a:pgadmin:pgadmin_4:5.6
-
cpe:2.3:a:pgadmin:pgadmin_4:5.7
-
cpe:2.3:a:pgadmin:pgadmin_4:6.0
-
cpe:2.3:a:pgadmin:pgadmin_4:6.1
-
cpe:2.3:a:pgadmin:pgadmin_4:6.10
-
cpe:2.3:a:pgadmin:pgadmin_4:6.11
-
cpe:2.3:a:pgadmin:pgadmin_4:6.12
-
cpe:2.3:a:pgadmin:pgadmin_4:6.13
-
cpe:2.3:a:pgadmin:pgadmin_4:6.14
-
cpe:2.3:a:pgadmin:pgadmin_4:6.15
-
cpe:2.3:a:pgadmin:pgadmin_4:6.16
-
cpe:2.3:a:pgadmin:pgadmin_4:6.17
-
cpe:2.3:a:pgadmin:pgadmin_4:6.18
-
cpe:2.3:a:pgadmin:pgadmin_4:6.19
-
cpe:2.3:a:pgadmin:pgadmin_4:6.2
-
cpe:2.3:a:pgadmin:pgadmin_4:6.20
-
cpe:2.3:a:pgadmin:pgadmin_4:6.21
-
cpe:2.3:a:pgadmin:pgadmin_4:6.3
-
cpe:2.3:a:pgadmin:pgadmin_4:6.4
-
cpe:2.3:a:pgadmin:pgadmin_4:6.5
-
cpe:2.3:a:pgadmin:pgadmin_4:6.6
-
cpe:2.3:a:pgadmin:pgadmin_4:6.7
-
cpe:2.3:a:pgadmin:pgadmin_4:6.8
-
cpe:2.3:a:pgadmin:pgadmin_4:6.9
-
cpe:2.3:a:pgadmin:pgadmin_4:7.0
-
cpe:2.3:a:pgadmin:pgadmin_4:7.1
-
cpe:2.3:a:pgadmin:pgadmin_4:7.2
-
cpe:2.3:a:pgadmin:pgadmin_4:7.3
-
cpe:2.3:a:pgadmin:pgadmin_4:7.4
-
cpe:2.3:a:pgadmin:pgadmin_4:7.5
-
cpe:2.3:a:pgadmin:pgadmin_4:7.6
-
cpe:2.3:a:pgadmin:pgadmin_4:7.7
-
cpe:2.3:a:pgadmin:pgadmin_4:7.8
-
cpe:2.3:a:pgadmin:pgadmin_4:8.0
-
cpe:2.3:a:pgadmin:pgadmin_4:8.1
-
cpe:2.3:a:pgadmin:pgadmin_4:8.10
-
cpe:2.3:a:pgadmin:pgadmin_4:8.11
-
cpe:2.3:a:pgadmin:pgadmin_4:8.12
-
cpe:2.3:a:pgadmin:pgadmin_4:8.13
-
cpe:2.3:a:pgadmin:pgadmin_4:8.14
-
cpe:2.3:a:pgadmin:pgadmin_4:8.2
-
cpe:2.3:a:pgadmin:pgadmin_4:8.3
-
cpe:2.3:a:pgadmin:pgadmin_4:8.4
-
cpe:2.3:a:pgadmin:pgadmin_4:8.5
-
cpe:2.3:a:pgadmin:pgadmin_4:8.6
-
cpe:2.3:a:pgadmin:pgadmin_4:8.7
-
cpe:2.3:a:pgadmin:pgadmin_4:8.8
-
cpe:2.3:a:pgadmin:pgadmin_4:8.9
-
cpe:2.3:a:pgadmin:pgadmin_4:9.0
-
cpe:2.3:a:pgadmin:pgadmin_4:9.1
-
cpe:2.3:a:pgadmin:pgadmin_4:9.10
-
cpe:2.3:a:pgadmin:pgadmin_4:9.11
-
cpe:2.3:a:pgadmin:pgadmin_4:9.12
-
cpe:2.3:a:pgadmin:pgadmin_4:9.13
-
cpe:2.3:a:pgadmin:pgadmin_4:9.14
-
cpe:2.3:a:pgadmin:pgadmin_4:9.15
-
cpe:2.3:a:pgadmin:pgadmin_4:9.2
-
cpe:2.3:a:pgadmin:pgadmin_4:9.3
-
cpe:2.3:a:pgadmin:pgadmin_4:9.4
-
cpe:2.3:a:pgadmin:pgadmin_4:9.5
-
cpe:2.3:a:pgadmin:pgadmin_4:9.6
-
cpe:2.3:a:pgadmin:pgadmin_4:9.7
-
cpe:2.3:a:pgadmin:pgadmin_4:9.8
-
cpe:2.3:a:pgadmin:pgadmin_4:9.9