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:
-
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.
-
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.
-
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.
CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
CVSS Score: 8.8
The 8.8 is earned by the stored pgstattuple / pgstatindex sinks (commit 2ae0d3610). The chain: a low-privilege user with CREATE on a schema names a table or index containing an apostrophe (e.g. foo'bar); pgAdmin's stats templates render that identifier inside a string literal -- pgstattuple('schema.foo'bar') -- when a different user views statistics on the object. If the viewing user is a PostgreSQL superuser, the SQL injection executes under the superuser role, reaching COPY ... TO/FROM PROGRAM and OS code execution on the DB host. The privilege crossing (low-priv planter -> superuser viewer) is what justifies C:H/I:H/A:H even with S:U: the impact is felt by a different security principal than the attacker, but it lands inside the same DB authority.
The originally-reported Domain Dialog description field is the same code-class but is self-SQLi -- the user injecting the apostrophe is the user whose role runs it. That sub-vector alone would score in the #10026 range (4.3 MEDIUM); it is bundled here because the fix is the same qtLiteral plumbing across all sixteen sites.
S:U because pgAdmin does not mediate a privilege boundary between the planter, the viewer, and the DB role; the boundary that is crossed lives entirely inside PostgreSQL's privilege model.
| Attack Vector |
Network |
Scope |
Unchanged |
| Attack Complexity |
Low |
Confidentiality Impact |
High |
| Privileges Required |
Low |
Integrity Impact |
High |
| User Interaction |
None |
Availability Impact |
High |
The 8.8 is earned by the stored pgstattuple / pgstatindex sinks (commit 2ae0d3610). The chain: a low-privilege user with CREATE on a schema names a table or index containing an apostrophe (e.g. foo'bar); pgAdmin's stats templates render that identifier inside a string literal -- pgstattuple('schema.foo'bar') -- when a different user views statistics on the object. If the viewing user is a PostgreSQL superuser, the SQL injection executes under the superuser role, reaching COPY ... TO/FROM PROGRAM and OS code execution on the DB host. The privilege crossing (low-priv planter -> superuser viewer) is what justifies C:H/I:H/A:H even with S:U: the impact is felt by a different security principal than the attacker, but it lands inside the same DB authority.
The originally-reported Domain Dialog description field is the same code-class but is self-SQLi -- the user injecting the apostrophe is the user whose role runs it. That sub-vector alone would score in the #10026 range (4.3 MEDIUM); it is bundled here because the fix is the same qtLiteral plumbing across all sixteen sites.
S:U because pgAdmin does not mediate a privilege boundary between the planter, the viewer, and the DB role; the boundary that is crossed lives entirely inside PostgreSQL's privilege model.
CVSS 3.1
CVSS Vector: 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
CVSS Score: 8.7
Same reasoning as the CVSS 3.1 entry: the stored pgstattuple sink is the load-bearing impact (low-priv planter, superuser viewer, superuser-role SQL). VC:H/VI:H/VA:H from the COPY ... TO PROGRAM reach; SC/SI/SA:N because pgAdmin is not the security authority being crossed -- the boundary lives in PostgreSQL.
| Exploitability Metrics |
Vulnerable System Impact Metrics |
Subsequent System Impact Metrics |
| Attack Vector |
Network |
Confidentiality |
High |
Confidentiality |
None |
| Attack Complexity |
Low |
Integrity |
High |
Integrity |
None |
| Attack Requirements |
None |
Availability |
High |
Availability |
None |
| Privileges Required |
Low |
| User Interaction |
None |
Same reasoning as the CVSS 3.1 entry: the stored pgstattuple sink is the load-bearing impact (low-priv planter, superuser viewer, superuser-role SQL). VC:H/VI:H/VA:H from the COPY ... TO PROGRAM reach; SC/SI/SA:N because pgAdmin is not the security authority being crossed -- the boundary lives in PostgreSQL.
CVSS 4.0