{"cve":{"cve_id":"CVE-2026-12044","is_kev":false,"kev_date_added":null,"kev_vendor_project":null,"kev_product":null,"kev_vulnerability_name":null,"kev_short_description":null,"kev_required_action":null,"kev_due_date":null,"kev_known_ransomware":null,"kev_notes":null,"kev_cwes":null,"epss_score":0.00513,"epss_percentile":0.39629,"epss_as_of":"2026-06-23","description":"SQL injection in pgAdmin 4 across every dialog template that renders ``COMMENT ON ... IS '<description>'`` 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.\n\nThe 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.\n\nFix is layered:\n\n  1. Sites: replace every ``'{{ x.description }}'`` with ``{{ x.description|qtLiteral(conn) }}`` (no surrounding quotes -- the filter wraps the value in escaped quotes itself). Plumb ``conn=self.conn`` through every ``render_template`` call that loads one of these templates. Also corrects a ``{ % elif`` Jinja typo in the foreign-table schema diff (dead branch). Rewrite the ten pgstattuple/pgstatindex stats sites to address the relation via OID + ``::oid::regclass`` cast (e.g. ``pgstattuple({{ tid }}::oid::regclass)``), eliminating the embedded literal-call form entirely so that bug-class can no longer recur there.\n\n  2. Driver hardening: ``qtLiteral`` (in ``utils/driver/psycopg3/__init__.py``) used to silently return the raw unescaped value when its ``conn`` argument was falsy. It now raises ``ValueError`` -- surfacing the entire bug class going forward. The change immediately uncovered eight latent plumbing bugs (in ``schemas/__init__.py``, ``schemas/functions/__init__.py``, ``schemas/tables/utils.py``, ``foreign_servers/__init__.py``, and seven sites in ``roles/__init__.py``) -- all fixed as part of this patch. The inner ``except`` block that swallowed adapter-level failures and returned the raw value is also removed, so unadaptable inputs raise instead of leaking unescaped values.\n\n  3. Regression tests: a per-template behavioural test renders each previously-vulnerable template with an apostrophe-injection payload and asserts the escaped fragment is present and the vulnerable fragment absent; a lint test walks every ``*.sql`` template flagging any ``'{{ ... }}'`` single-quote-wrapped interpolation against an explicit allowlist; unit tests cover the new qtLiteral fail-fast and inner-except raise paths.\n\nThis issue affects pgAdmin 4: from 1.0 before 9.16.","published_at":"2026-06-18T23:37:16.202000Z","last_modified_at":null,"cvss_v3_score":8.8,"cvss_v3_vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","cvss_v3_severity":"HIGH","cvss_v4_score":8.7,"cvss_v4_vector":"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","cvss_v4_severity":"HIGH","ssvc_decision":null,"ssvc_exploitation":null,"ssvc_automatable":null,"ssvc_technical_impact":null,"cwes":["CWE-89","CWE-116"],"nvd_references":["https://github.com/pgadmin-org/pgadmin4/issues/10078","https://github.com/pgadmin-org/pgadmin4/commit/658bb585d","https://github.com/pgadmin-org/pgadmin4/commit/2ae0d3610"],"vuln_status":null,"trending_score":null,"is_trending":false,"has_trended":false,"trended_number_one":false,"trending_peak_score":null,"trending_peak_rank":null,"started_trending_at":null,"trended_number_one_at":null,"summary_generated":null,"summary_generated_at":null,"summary_model":null,"created_at":"2026-06-24T00:09:39.878444Z","updated_at":"2026-06-28T23:28:56.380351Z"},"effective_severity":"HIGH","badges":[],"impact_analysis":[],"cvss_v3_decoded":{"version":"3.1","metrics":[{"metric":"AV","name":"Attack Vector","value":"N","value_label":"Network"},{"metric":"AC","name":"Attack Complexity","value":"L","value_label":"Low"},{"metric":"PR","name":"Privileges Required","value":"L","value_label":"Low"},{"metric":"UI","name":"User Interaction","value":"N","value_label":"None"},{"metric":"S","name":"Scope","value":"U","value_label":"Unchanged"},{"metric":"C","name":"Confidentiality","value":"H","value_label":"High"},{"metric":"I","name":"Integrity","value":"H","value_label":"High"},{"metric":"A","name":"Availability","value":"H","value_label":"High"}]},"cvss_v4_decoded":{"version":"4.0","metrics":[{"metric":"AV","name":"Attack Vector","value":"N","value_label":"Network"},{"metric":"AC","name":"Attack Complexity","value":"L","value_label":"Low"},{"metric":"AT","name":"Attack Requirements","value":"N","value_label":"None"},{"metric":"PR","name":"Privileges Required","value":"L","value_label":"Low"},{"metric":"UI","name":"User Interaction","value":"N","value_label":"None"},{"metric":"VC","name":"Confidentiality (Vulnerable System)","value":"H","value_label":"High"},{"metric":"VI","name":"Integrity (Vulnerable System)","value":"H","value_label":"High"},{"metric":"VA","name":"Availability (Vulnerable System)","value":"H","value_label":"High"},{"metric":"SC","name":"Confidentiality (Subsequent System)","value":"N","value_label":"None"},{"metric":"SI","name":"Integrity (Subsequent System)","value":"N","value_label":"None"},{"metric":"SA","name":"Availability (Subsequent System)","value":"N","value_label":"None"}]},"affected":[{"vendor_slug":"pgadmin.org","vendor_name":"pgadmin.org","product_slug":"pgadmin-4","product_name":"pgAdmin 4","version_start":"1.0","version_start_inclusive":true,"version_end":"9.16","version_end_inclusive":false,"cpe23_uri":"cve5:pgadmin.org:pgadmin-4:1.0:9.16"}],"exploit_refs":[],"news":[],"references":[{"url":"https://github.com/pgadmin-org/pgadmin4/issues/10078","source_type":"MISC","tags":[]},{"url":"https://github.com/pgadmin-org/pgadmin4/commit/658bb585d","source_type":"PATCH","tags":["patch"]},{"url":"https://github.com/pgadmin-org/pgadmin4/commit/2ae0d3610","source_type":"PATCH","tags":["patch"]}],"timeline":[{"type":"published","at":"2026-06-18T23:37:16.202000Z","label":"CVE published","source":null},{"type":"cvss_changed","at":"2026-06-28T17:50:40.391234Z","label":"CVSS score revised","source":"cvelistv5"},{"type":"cvss_changed","at":"2026-06-28T17:50:40.391234Z","label":"CVSS score revised","source":"cvelistv5"},{"type":"cvss_changed","at":"2026-06-28T17:50:40.391234Z","label":"CVSS score revised","source":"cvelistv5"},{"type":"cvss_changed","at":"2026-06-28T17:50:40.391234Z","label":"CVSS score revised","source":"cvelistv5"},{"type":"cvss_changed","at":"2026-06-28T17:50:40.391234Z","label":"CVSS score revised","source":"cvelistv5"},{"type":"cvss_changed","at":"2026-06-28T17:50:40.391234Z","label":"CVSS score revised","source":"cvelistv5"}]}