CVE-2026-12044
published 2026-07-31CVE-2026-12044: 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…
PriorityP359high8.8CVSS 3.1
AVNACLPRLUINSUCHIHAH
EPSS
0.71%
51.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
4 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| pgadmin.org | pgadmin_4 | >= 1.0 < 9.17 | 9.17 |
| pgadmin.org | pgadmin_4 | >= 5.0 < 9.17 | 9.17 |
| pgadmin | pgadmin_4 | >= 1.0 < 9.17 | 9.17 |
| pgadmin | pgadmin_4 | >= 1.0 < 9.16 | 9.16 |
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
Citrix
Citrix Security Bulletin CTX249976
vendor_citrix·CVSS 7.5
CVE-2019-12044 [HIGH] Citrix Security Bulletin CTX249976
Citrix Security Bulletin CTX249976
CVE References: CVE-2019-12044, CVE-2025-12101, CVE-2025-62626, CVE-2026-23554, CVE-2026-3055, CVE-2026-4368, CVE-2026-4397
Affected Products: Citrix ADM, Citrix Hypervisor, Citrix Virtual Apps and Desktops, Endpoint Management, NetScaler ADC, NetScaler Gateway, XenServer
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
GHSA
SQL injection in pgAdmin 4 across every dialog template that renders ``COMMENT ON ...
ghsa_unreviewed·2026-06-19
CVE-2026-12044 [HIGH] CWE-89 SQL injection in pgAdmin 4 across every dialog template that renders ``COMMENT ON ...
SQL injection in pgAdmin 4 across every dialog template that renders ``COMMENT ON ... IS ''`` for a user-supplied description field. The Jinja templates for Domains (and their constraints), Foreign Tables, Languages, and Event Triggers, plus the Views OID-lookup query, interpolated the description directly inside a single-quoted SQL literal -- ``'{{ data.description }}'`` -- instead of passing it through the ``qtLiteral`` escape filter. An authenticated pgAdmin user with permission to create or alter the affected object types could submit a description containing an apostrophe, break out of the literal and chain arbitrary SQL. The injected SQL runs under the PostgreSQL role the user is already authenticated as; for a connected role with ``COPY ... TO/FROM PROGRAM`` (typically PostgreSQL su
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
Bugzilla
CVE-2026-12044 pgadmin4: pgAdmin 4: Arbitrary code execution via SQL injection [fedora-all]
bugzilla·2026-06-19
CVE-2026-12044 [HIGH] CVE-2026-12044 pgadmin4: pgAdmin 4: Arbitrary code execution via SQL injection [fedora-all]
CVE-2026-12044 pgadmin4: pgAdmin 4: Arbitrary code execution via SQL injection [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.
Discussion:
FEDORA-2026-c248414214 (pgadmin4-9.16-1.fc44) has been submitted as an update to Fedora 44.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-c248414214
---
FEDORA-2026-5938be3b09 (pgadmin4-9.16-1.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-5938be3b09
---
FEDORA-2026-c248414214 has been pushed to the Fedora 44 testing repository.
Soon you'll be able to install the update with the following command:
`
Bugzilla
CVE-2026-12044 pgadmin4: pgAdmin 4: Arbitrary code execution via SQL injection
bugzilla·2026-06-19
CVE-2026-12044 [HIGH] CVE-2026-12044 pgadmin4: pgAdmin 4: Arbitrary code execution via SQL injection
CVE-2026-12044 pgadmin4: pgAdmin 4: Arbitrary code execution via SQL injection
SQL injection in pgAdmin 4 across every dialog template that renders ``COMMENT ON ... IS ''`` for a user-supplied description field. The Jinja templates for Domains (and their constraints), Foreign Tables, Languages, and Event Triggers, plus the Views OID-lookup query, interpolated the description directly inside a single-quoted SQL literal -- ``'{{ data.description }}'`` -- instead of passing it through the ``qtLiteral`` escape filter. An authenticated pgAdmin user with permission to create or alter the affected object types could submit a description containing an apostrophe, break out of the literal and chain arbitrary SQL. The injected SQL runs under the PostgreSQL role the user is already authenticated as;
Hackernews
⚡ Weekly Recap: Proxy Botnets, Browser Ransomware, AI Agent Tricks, Fake PoC Malware and More
blogs_hackernews·2026-07-06
CVE-2026-48276 ⚡ Weekly Recap: Proxy Botnets, Browser Ransomware, AI Agent Tricks, Fake PoC Malware and More
Home
Threat Intelligence
Vulnerabilities
Cyber Attacks
Webinars
Expert Insights
Awards
Webinars
Awards
Free eBooks
About THN
Jobs
Advertise with us
## ⚡ Weekly Recap: Proxy Botnets, Browser Ransomware, AI Agent Tricks, Fake PoC Malware and More
A streaming box should not need a threat model. Neither should a username field, a demo repo, a reset flow, or a browser permission prompt. That is the irritating part this week: the risky pieces were ordinary.
Home devices became a routing cover. Clean code pulled dirt from a dependency. Identity shortcuts aged badly. AI systems trusted the wrong instructions. Same soft spot throughout: trust placed one layer too early.
Below is the full recap, since this is apparently what counted as a normal week.
## ⚡ Threat of the Week
Net
2026-07-31
Published