Severity by source
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
Network-delivered via web UI (AV:N); attacker needs object-creation privilege (PR:L); victim must navigate to the affected tab (UI:R); injected SQL executes in victim's PostgreSQL session under victim's credentials, constituting a scope change (S:C).
Primary rating from Vendor (f86ef6dc-4d3a-42ad-8f28-e6d5547a5007).
CVSS VectorVendor: f86ef6dc-4d3a-42ad-8f28-e6d5547a5007
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
Lifecycle Timeline
4DescriptionCVE.org
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.
Articles & Coverage 1
AnalysisAI
SQL injection in pgAdmin 4 through an incomplete remediation of CVE-2026-12044 allows a low-privileged authenticated user to execute arbitrary SQL in a higher-privileged victim's database session. By creating a PostgreSQL object - table, index, publication, or subscription - with an apostrophe in its name (a character PostgreSQL legally permits in quoted identifiers), the attacker plants a payload that fires the moment any other pgAdmin user opens the object's Statistics or Dependencies tab, triggering raw Jinja2 template interpolation in coll_stats.sql, dependencies.sql, and get_position.sql without the qtLiteral escaping applied by the prior fix. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Exploitation requires the attacker to hold a low-privileged pgAdmin and PostgreSQL account on the same instance as potential victims, with at least one of the following object-creation privileges granted: CREATE TABLE or CREATE INDEX (to exploit the Index Statistics coll_stats.sql sink, present since pgAdmin 1.0), CREATE PUBLICATION (to exploit the Publications dependencies.sql and get_position.sql sinks, present since pgAdmin 5.0), or CREATE SUBSCRIPTION (to exploit the Subscriptions dependencies.sql and get_position.sql sink, present since pgAdmin 5.0). … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) reflects severe confidentiality, integrity, and availability impact over a network with low complexity. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | A low-privileged developer with a shared pgAdmin account and CREATE TABLE rights on a team PostgreSQL instance creates a table named using PostgreSQL quoted-identifier syntax that embeds an apostrophe followed by injected SQL - for example, naming the table such that, when its name is interpolated into coll_stats.sql as `schemaname = 'public' AND stat.relname = '<name>'`, the apostrophe breaks out of the string literal. When a database administrator later opens the Index Statistics tab for that schema's indexes in pgAdmin's browser tree, the unescaped `{{table}}` substitution executes the attacker's injected statement in the DBA's database session with the DBA's credentials. … |
| Remediation | Upgrade to pgAdmin 4 9.17, which applies `qtLiteral(conn)` escaping to all previously unescaped template sinks and removes the incorrect ALLOWLIST entries from `test_sql_string_literal_lint.py`. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours: inventory all pgAdmin 4 deployments, document affected versions, and identify which users have object-creation privileges. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
More in PostgreSQL
View allPostgreSQL libpq functions PQescapeLiteral(), PQescapeIdentifier(), PQescapeString(), and PQescapeStringConn() improperl
An issue was discovered in Appsmith before 1.52. Rated critical severity (CVSS 9.8), this vulnerability is remotely expl
Argument injection vulnerability in PostgreSQL 9.2.x before 9.2.4, 9.1.x before 9.1.9, and 9.0.x before 9.0.13 allows re
Unauthenticated arbitrary file write in Splunk Enterprise (below 10.2.4 and 10.0.7) and Splunk Cloud Platform (below 10.
PostgreSQL versions before 9.2.22, 9.3.18, 9.4.13, 9.5.8 and 9.6.4 are vulnerable to incorrect authentication flaw allow
The build_tablename function in pgsql.c in the PostgreSQL (aka pgsql) extension in PHP through 5.6.7 does not validate t
A vulnerability in the h2oai/h2o-3 REST API versions 3.46.0.4 allows unauthenticated remote attackers to execute arbitra
In PostgreSQL 9.3 through 11.2, the "COPY TO/FROM PROGRAM" function allows superusers and users in the 'pg_execute_serve
Unauthenticated SQL injection in Vendure Shop API allows remote attackers to execute arbitrary SQL commands against the
Parse Server is an open source http web server backend. Rated critical severity (CVSS 10.0), this vulnerability is remot
Hard-coded default PostgreSQL credentials shipped in the docker-compose.yaml of langgenius Dify through version 1.5.1 al
A vulnerability in the FinanceChatLlamaPack of the run-llama/llama_index repository, versions up to v0.12.3, allows for
Same weakness CWE-89 – SQL Injection
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-51559
GHSA-vmj8-4452-jj72