CVE-2026-12044
published 2026-06-19CVE-2026-12044: SQL injection in pgAdmin 4 across every dialog template that renders ``COMMENT ON ... IS ''`` for a user-supplied description field. The Jinja templates for…
PriorityP359high8.8CVSS 3.1
AVNACLPRLUINSUCHIHAH
EPSS
0.51%
39.8th percentile
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 superuser), this chains to OS command execution on the PostgreSQL host. The defect does not cross a privilege boundary -- the user already has direct SQL access to that role through pgAdmin's Query Tool -- so the attacker gains no capability beyond what their database role already grants. The marginal impact captures bypass of any application-layer Query Tool gating an operator may have configured.
The defect was originally reported against the Domain Dialog ``description`` field; a code-wide audit identified sixteen sites of the same pattern across the templates listed above. The same review also surfaced ten related sinks in the pgstattuple/pgstatindex stats templates -- ``pgstattuple('{{schema}}.{{table}}')`` and the matching pgstatindex shape -- where ``qtIdent`` escapes embedded double quotes inside the identifier but not apostrophes, so a user with CREATE privilege on a schema could plant a table or index named ``foo'bar`` and a later stats viewer would render an unbalanced literal.
Fix is layered:
1. Sites: replace every ``'{{ x.description }}'`` with ``{{ x.description|qtLiteral(conn) }}`` (no surrounding quotes -- the filter wraps the value in escaped quotes itself). Plum
Affected
1 ranges
| Vendor | Product | Version range | Fixed in |
|---|---|---|---|
| pgadmin.org | 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
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.
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
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
No detection rules found.
No public exploits indexed.
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;
2026-06-19
Published