pgadmin-org pgAdmin prior 9.17 SQL Template Rendering __init__.py render_template injection

Summaryinfo

A vulnerability was found in pgadmin-org pgAdmin. It has been declared as critical. This affects 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. Executing a manipulation can lead to injection. This vulnerability is registered as CVE-2026-17346. It is possible to launch the attack remotely. No exploit is available.

Detailsinfo

A vulnerability was found in pgadmin-org pgAdmin. It has been declared as critical. This vulnerability affects 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. The manipulation with an unknown input leads to a injection vulnerability. The CWE definition for the vulnerability is CWE-74. The product constructs all or part of a command, data structure, or record using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify how it is parsed or interpreted when it is sent to a downstream component. As an impact it is known to affect confidentiality, integrity, and availability. CVE summarizes:

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.

The advisory is available at github.com. This vulnerability was named CVE-2026-17346 since 07/25/2026. The exploitation appears to be easy. The attack can be initiated remotely. Successful exploitation requires user interaction by the victim. Technical details are known, but there is no available exploit. This vulnerability is assigned to T1055 by the MITRE ATT&CK project.

Upgrading to version 9.17 eliminates this vulnerability.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Productinfo

Vendor

• pgadmin-org

Name

• pgAdmin

CPE 2.3info

• 🔒

CPE 2.2info

• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Discussion