CVE-2026-17346
Last modified
CVE-2026-17346 is a high-severity vulnerability rated 8.8/10 on the CVSS scale. 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. EPSS estimates a 0.43% chance of exploitation in the next 30 days.
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.
Metrics
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
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/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
Weakness Enumeration
Affected Software
| Vendor | Product | Versions |
|---|---|---|
| Pgadmin | Pgadmin 4 | >= 1.0, < 9.17 |
References
Timeline
- Published
- Last Modified
- Status
- Analyzed
Frequently Asked Questions
What is CVE-2026-17346?
How severe is CVE-2026-17346?
How do I fix CVE-2026-17346?
How Strix Helps
- How Strix found a critical auth bypass in etcdStrix autonomously discovered a critical authentication bypass in etcd, later designated CVE-2026-33413.
- Autonomous PentestingAI agents that find and validate exploitable vulnerabilities like this one across your applications.
- PR ReviewsPentest every pull request so vulnerable code is caught before it ships to production.
- AI Penetration TestingHow AI-driven penetration testing continuously covers your attack surface.
Related CVEs from 2026
- CVE-2026-1729The AdForest theme for WordPress is vulnerable to authentica…9.8
- CVE-2026-1730The OS DataHub Maps plugin for WordPress is vulnerable to ar…8.8
- CVE-2026-1731BeyondTrust Remote Support (RS) and certain older versions o…9.8
- CVE-2026-1732GitLab has remediated an issue in GitLab CE/EE affecting all…4.3
- CVE-2026-1733A vulnerability was identified in Zhong Bang CRMEB up to 5.6…4.3
- CVE-2026-1734A security flaw has been discovered in Zhong Bang CRMEB up t…5.5
- CVE-2026-17347The MASTER_PASSWORD_HOOK setting, introduced in pgAdmin 4 7.…8.8
- CVE-2026-17348In SERVER mode, pgAdmin 4 enforces authentication per route …6.9
- CVE-2026-17349/misc/workspace/adhoc_connect_server, part of the Workspaces…9.6
- CVE-2026-1735A weakness has been identified in Yealink MeetingBar A30 133…4.3
- CVE-2026-17350The per-tool permission system (custom roles / role-based to…5.4
- CVE-2026-17351The fix for CVE-2026-12045 in pgAdmin 4 9.16 required the LL…9
Are you affected by CVE-2026-17346?
Run a free Strix scan to check your systems for this vulnerability.
Scan your code nowSource: NVD / NIST
