CVE-2026-17346
published 2026-07-31CVE-2026-17346: 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…
PriorityP355high8.8CVSS 3.1
AVNACLPRLUINSUCHIHAH
EPSS
0.43%
36.9th percentile
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 affe
Affected
1 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| pgadmin | pgadmin_4 | >= 1.0 < 9.17 | 9.17 |
CVSS provenance
nvdv3.18.8HIGHCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
nvdv4.08.7HIGHCVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
vendor_redhat8.8HIGH
Stop checking back — get the weekly exploitation signal.
Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.
Red Hat
pgAdmin 4: pgAdmin 4: SQL injection via unescaped object names
vendor_redhat·2026-07-31·CVSS 8.8
CVE-2026-17346 [HIGH] CWE-89 pgAdmin 4: pgAdmin 4: SQL injection via unescaped object names
pgAdmin 4: pgAdmin 4: SQL injection via unescaped object names
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 St
GHSA
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_s
ghsa_unreviewed·2026-07-31·CVSS 8.8
CVE-2026-17346 [HIGH] CWE-89 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_s
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 i
VulDB
pgadmin-org pgAdmin prior 9.17 SQL Template Rendering __init__.py render_template injection
vuldb·2026-07-31·CVSS 8.8
CVE-2026-17346 [HIGH] pgadmin-org pgAdmin prior 9.17 SQL Template Rendering __init__.py render_template injection
A vulnerability was found in pgadmin-org pgAdmin. It has been classified as problematic. Affected by this issue is the function render_template of the file coll_stats.sql/dependencies.sql/get_position.sql/publications/__init__.py/subscriptions/__init__.py of the component SQL Template Rendering. Performing a manipulation results in injection.
This vulnerability is cataloged as CVE-2026-17346. It is possible to initiate the attack remotely. There is no exploit available.
Upgrading the affected component is recommended.
No detection rules found.
No public exploits indexed.
Bugzilla
CVE-2026-17346 pgadmin4: pgAdmin 4: SQL injection via unescaped object names [fedora-all]
bugzilla·2026-08-12·CVSS 8.8
CVE-2026-17346 [HIGH] CVE-2026-17346 pgadmin4: pgAdmin 4: SQL injection via unescaped object names [fedora-all]
CVE-2026-17346 pgadmin4: pgAdmin 4: SQL injection via unescaped object names [fedora-all]
Disclaimer: Community trackers are created by Red Hat Product Security team on a best effort basis. Package maintainers are required to ascertain if the flaw indeed affects their package, before starting the update process.
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 use
Bugzilla
CVE-2026-17346 pgAdmin 4: pgAdmin 4: SQL injection via unescaped object names
bugzilla·2026-07-31·CVSS 8.8
CVE-2026-17346 [HIGH] CVE-2026-17346 pgAdmin 4: pgAdmin 4: SQL injection via unescaped object names
CVE-2026-17346 pgAdmin 4: pgAdmin 4: SQL injection via unescaped object names
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 t
2026-07-31
Published