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 rendertemplate 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, foreignservers/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.

The fix for CVE-2026-12044 in pgAdmin 4 9.16 hardened qtLiteral and switched sixteen COMMENT ON / pgstattuple / pgstatindex templates to it, but missed several sinks that had been placed in testsqlstringliterallint.py's ALLOWLIST on the incorrect assumption that schema, table, publication, and subscription names sourced from pgcatalog via the browser tree could never contain an apostrophe. PostgreSQL permits arbitrary characters in quoted identifiers, so a low-privileged user able to CREATE TABLE, CREATE PUBLICATION, or CREATE SUBSCRIPTION can plant an apostrophe'd object name that breaks out of the unescaped '{{ name }}' template interpolation the moment any user (including a higher-privileged one) opens that object's Statistics or Dependencies tab, allowing arbitrary SQL statement injection in the viewing user's database session.

Affected sinks: the Index Statistics query for all-indexes listing (collstats.sql, both the 16plus and default PostgreSQL-version template variants -- distinct from the single-index stats.sql path already fixed in CVE-2026-12044), and the publication and subscription dependencies.sql / getposition.sql templates (both the pg and ppas/EPAS dialect variants for publications).

Fix switches all of these templates to qtLiteral(conn) for name interpolation, and updates publications/init.py and subscriptions/init.py to pass conn=self.conn into the dependencies.sql rendertemplate call so the qtLiteral filter has a connection to quote against. The corresponding ALLOWLIST entries in testsqlstringliterallint.py are removed now that these sinks are properly escaped rather than merely assumed safe. A behavioral regression test renders each fixed template with a stacked-statement apostrophe payload and asserts both that the object name appears exactly as qtLiteral-escaped and that the rendered SQL parses as exactly one statement, verifying the assertion genuinely fails against the pre-patch raw-interpolation form.

This issue affects pgAdmin 4: the Index Statistics sink from 1.0, and the Publications/Subscriptions sinks from 5.0, both before 9.17.

In SERVER mode, pgAdmin 4 enforces authentication per route via the @pgaloginrequired decorator; the application's beforerequest hook only handles desktop-mode auto-login and the Kerberos/Webserver-auth redirect, so any route shipped without the decorator is reachable without authentication (CWE-306). This is the same defect class previously fixed as CVE-2026-12046 (the sqleditor close/updateconnection routes).

A follow-up sweep, prompted by a report describing an incomplete fix for CVE-2026-12046, found further routes missing @pgaloginrequired: the Constraints blueprint's nodes and proplist (object listing) routes and its delete route (a state-mutating DELETE that removes table constraints); preferences.getallcli (GET, discloses all CLI-settable preference values); debugger.close (DELETE); and schemadiff.close (DELETE). An unauthenticated network client could therefore enumerate constraint metadata, delete table constraints, read preference values, and force-close debugger or schema-diff sessions belonging to other users, without ever authenticating.

Fix adds the missing @pgaloginrequired decorator (and the corresponding import to the Constraints module) to each of these routes. The change is decorator-only; no behavioral changes to the underlying handlers.

This issue affects pgAdmin 4 in SERVER mode: the Constraints and Debugger routes from 1.0, the Schema Diff close route from 4.18, and preferences.getallcli from 8.2, all before 9.17.

SQL injection in pgAdmin 4's named restore point endpoint (POST /browser/server/restorepoint/{gid}/{sid}). The user-supplied 'value' field was interpolated directly into the SQL string with str.format() instead of being passed as a bound parameter, allowing an authenticated pgAdmin user with a connected PostgreSQL session to inject additional statements through that endpoint.

The injected SQL executes under the database role the user is already authenticated as. The defect does not cross a privilege boundary -- the user already has direct SQL access to that role through the Query Tool -- so the attacker gains no capability beyond what their database role already grants them. The marginal impact accounts for the fact that the injection path is not the documented SQL-execution interface, so a deployment that gates the Query Tool at the application layer could see SQL executed through a path it did not anticipate.

Fix passes the restore point name as a bound parameter and schema-qualifies the function call as pgcatalog.pgcreaterestorepoint so a non-default searchpath on the connection cannot redirect the call to a shadow definition. A regression test asserts the value arrives as a bound parameter and not spliced into the SQL string.

This issue affects pgAdmin 4: from 1.0 before 9.16.