pgAdmin 4: SQL injection via unescaped object names in index Statistics and publication/subscription dependency views (incomplete fix for CVE-2026-12044)

Description

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 test_sql_string_literal_lint.py's ALLOWLIST on the incorrect assumption that schema, table, publication, and subscription names sourced from pg_catalog 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 (coll_stats.sql, both the 16_plus 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 / get_position.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 render_template call so the qtLiteral filter has a connection to quote against. The corresponding ALLOWLIST entries in test_sql_string_literal_lint.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.

Timeline

Scores

EPSS (exploitation in 30 days)

0.61% · top 50% of all CVEs (7 Nov 2026)

CISA SSVC

Exploitation: none · Automatable: no · Technical impact: total

The list uses the assigner's score when there is one, then CISA's, then NVD's: High 8.7.

Weakness

• CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') (opens in a new tab)All about CWE-89 and its CVEs

Affected products

• pgadmin.org · pgAdmin 4

  • affected 1.0 – < 9.17

• pgadmin.org · pgAdmin 4

  • affected 5.0 – < 9.17

References (3)

• https://github.com/pgadmin-org/pgadmin4/issues/10193 (opens in a new tab)issue-tracking
• https://github.com/pgadmin-org/pgadmin4/commit/73b3218992cc37af6e10b7e54eaeed6ec293c6b2 (opens in a new tab)patch
• https://github.com/pgadmin-org/pgadmin4/commit/f75452bfd0f786d0c071638919d48fc1d76f987d (opens in a new tab)patch

Sources

The same CVE in the primary databases and aggregators, to check against.

• CVE.org record (opens in a new tab)
• CVE List JSON (GitHub) (opens in a new tab)
• NVD (opens in a new tab)
• FIRST EPSS (opens in a new tab)
• OSV.dev (opens in a new tab)
• GitHub Advisories (opens in a new tab)
• CIRCL Vulnerability-Lookup (opens in a new tab)

Badge for a README or a ticket

[![CVE-2026-17346](https://trackcve.app/badge/CVE-2026-17346.svg)](https://trackcve.app/cve/CVE-2026-17346)

Record last updated 1 Aug 2026, 03:56 UTC.