CVE-2026-17346 in pgAdmin
Summary
by MITRE • 07/31/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/31/2026
The vulnerability described in CVE-2026-12044 represents a critical SQL injection flaw within pgAdmin 4 versions prior to 9.17, specifically targeting the handling of quoted identifiers in database object names. This weakness arises from an incomplete fix that addressed certain template interpolation sinks while overlooking others, creating a persistent attack surface for low-privileged users who can manipulate database schema elements. The root cause stems from the incorrect assumption that object names sourced from pg_catalog through the browser tree could never contain apostrophes, despite PostgreSQL's permissive approach to quoted identifiers that allows arbitrary characters. This misconfiguration enabled attackers to exploit template interpolation patterns where '{{ name }}' was used without proper escaping, particularly when users opened Statistics or Dependencies tabs for objects created by attackers.
The technical flaw manifests in multiple template files across pgAdmin 4's codebase, specifically affecting the Index Statistics query templates located in coll_stats.sql and the publication and subscription dependency templates found in dependencies.sql and get_position.sql. These templates utilize different PostgreSQL version variants and dialects, including both standard PostgreSQL and EPAS-specific implementations, creating a broad attack surface. The vulnerability operates through a sophisticated chained exploitation pattern where an attacker with minimal privileges can create database objects with apostrophe-containing names, then trigger the injection when other users access these objects' metadata tabs. This design flaw directly violates security principle of least privilege and demonstrates inadequate input validation at multiple layers of the application's data handling pipeline.
The operational impact of this vulnerability extends beyond simple code execution, as it enables arbitrary SQL statement injection within the database session of any user who accesses the affected object metadata. This creates a persistent threat vector where attackers can escalate privileges, extract sensitive data, modify database contents, or even establish persistence mechanisms within the target environment. The attack requires only minimal permissions to create database objects with malicious names, making it particularly dangerous in multi-user environments where different privilege levels coexist. This vulnerability type aligns with CWE-89 SQL Injection and maps to ATT&CK technique T1078 Valid Accounts for privilege escalation, as it leverages legitimate user sessions to execute malicious commands.
The fix implemented addresses the root cause by switching all affected template interpolation sinks to utilize qtLiteral(conn) for proper name interpolation, ensuring that object identifiers are properly escaped regardless of their content. This comprehensive approach requires updates to core application components including publications/_init_.py and subscriptions/_init_.py to pass the database connection context into rendering functions, enabling proper quoting mechanisms. The remediation process includes removing outdated ALLOWLIST entries in test_sql_string_literal_lint.py that previously permitted unsafe interpolation patterns, demonstrating a shift from assumption-based security to explicit validation. A behavioral regression test was implemented to validate that the fixed templates properly escape apostrophe-containing names and that rendered SQL statements parse correctly as single statements, providing confidence that the fix prevents both the injection vulnerability and maintains application functionality.
This vulnerability affects pgAdmin 4 across multiple versions with varying impact timelines: Index Statistics functionality has been vulnerable since version 1.0, while Publication and Subscription dependency handling remained exposed from version 5.0 through the affected releases. The patch resolution ensures that all template interpolation points now properly escape database object names regardless of their content, preventing attackers from exploiting this pathway to inject malicious SQL commands. The fix demonstrates proper security engineering practices by addressing all identified sinks rather than relying on incomplete assumptions about input sanitization, and includes comprehensive testing to validate that the remediation prevents actual exploitation while maintaining application functionality. This vulnerability highlights the importance of thorough security reviews during patch development and the necessity of validating assumptions about data sources in web application security contexts.