CVE-2026-12044 (GCVE-0-2026-12044)

Vulnerability from cvelistv5 – Published: 2026-06-18 23:37 – Updated: 2026-06-22 18:37
VLAI
Title
pgAdmin 4: SQL injection in COMMENT ON ... IS '<description>' rendering across dialog templates
Summary
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. 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). 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. 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. 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. This issue affects pgAdmin 4: from 1.0 before 9.16.
Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
8.7 (High)
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
SSVC
Exploitation: none Automatable: no Technical Impact: total
CISA Coordinator (v2.0.3)
CWE
  • CWE-89 - Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
  • CWE-116 - Improper Encoding or Escaping of Output
Assigner
References
Impacted products
Vendor Product Version
pgadmin.org pgAdmin 4 Affected: 1.0 , < 9.16 (custom)
Create a notification for this product.
Credits
Jasser Chebbi <jasserchebbi@outlook.com> Dave Page <dpage@pgadmin.org> Ashesh Vashi <ashesh.vashi@enterprisedb.com>
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-12044",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-06-22T18:36:59.059744Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-06-22T18:37:05.999Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "modules": [
            "Domains",
            "Domain Constraints",
            "Foreign Tables",
            "Languages",
            "Event Triggers",
            "Views",
            "Tables",
            "Indexes",
            "Index Constraints",
            "Exclusion Constraints",
            "Materialized Views",
            "Driver (qtLiteral)"
          ],
          "product": "pgAdmin 4",
          "programFiles": [
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/driver/psycopg3/__init__.py",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/browser/server_groups/servers/databases/schemas/domains/templates/domains/sql/default/create.sql",
            "https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/browser/server_groups/servers/databases/schemas/tables/templates/tables/sql/16_plus/stats.sql"
          ],
          "repo": "https://github.com/pgadmin-org/pgadmin4",
          "vendor": "pgadmin.org",
          "versions": [
            {
              "lessThan": "9.16",
              "status": "affected",
              "version": "1.0",
              "versionType": "custom"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "finder",
          "value": "Jasser Chebbi \u003cjasserchebbi@outlook.com\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Dave Page \u003cdpage@pgadmin.org\u003e"
        },
        {
          "lang": "en",
          "type": "remediation developer",
          "value": "Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e"
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "SQL injection in pgAdmin 4 across every dialog template that renders ``COMMENT ON ... IS \u0027\u003cdescription\u003e\u0027`` 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 -- ``\u0027{{ data.description }}\u0027`` -- 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\u0027s 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(\u0027{{schema}}.{{table}}\u0027)`` 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\u0027bar`` and a later stats viewer would render an unbalanced literal.\n\nFix is layered:\n\n  1. Sites: replace every ``\u0027{{ x.description }}\u0027`` 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 ``\u0027{{ ... }}\u0027`` 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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 8.8,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
            "version": "3.1"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "The 8.8 is earned by the stored pgstattuple / pgstatindex sinks (commit 2ae0d3610). The chain: a low-privilege user with CREATE on a schema names a table or index containing an apostrophe (e.g. foo\u0027bar); pgAdmin\u0027s stats templates render that identifier inside a string literal -- pgstattuple(\u0027schema.foo\u0027bar\u0027) -- when a *different* user views statistics on the object. If the viewing user is a PostgreSQL superuser, the SQL injection executes under the superuser role, reaching COPY ... TO/FROM PROGRAM and OS code execution on the DB host. The privilege crossing (low-priv planter -\u003e superuser viewer) is what justifies C:H/I:H/A:H even with S:U: the impact is felt by a different security principal than the attacker, but it lands inside the same DB authority.\n\nThe originally-reported Domain Dialog description field is the same code-class but is self-SQLi -- the user injecting the apostrophe is the user whose role runs it. That sub-vector alone would score in the #10026 range (4.3 MEDIUM); it is bundled here because the fix is the same qtLiteral plumbing across all sixteen sites.\n\nS:U because pgAdmin does not mediate a privilege boundary between the planter, the viewer, and the DB role; the boundary that is crossed lives entirely inside PostgreSQL\u0027s privilege model."
            }
          ]
        },
        {
          "cvssV4_0": {
            "baseScore": 8.7,
            "baseSeverity": "HIGH",
            "vectorString": "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",
            "version": "4.0"
          },
          "format": "CVSS",
          "scenarios": [
            {
              "lang": "en",
              "value": "Same reasoning as the CVSS 3.1 entry: the stored pgstattuple sink is the load-bearing impact (low-priv planter, superuser viewer, superuser-role SQL). VC:H/VI:H/VA:H from the COPY ... TO PROGRAM reach; SC/SI/SA:N because pgAdmin is not the security authority being crossed -- the boundary lives in PostgreSQL."
            }
          ]
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-89",
              "description": "CWE-89 Improper Neutralization of Special Elements used in an SQL Command (\u0027SQL Injection\u0027)",
              "lang": "en",
              "type": "CWE"
            },
            {
              "cweId": "CWE-116",
              "description": "CWE-116 Improper Encoding or Escaping of Output",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-06-18T23:37:16.202Z",
        "orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
        "shortName": "PostgreSQL"
      },
      "references": [
        {
          "tags": [
            "issue-tracking"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/issues/10078"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/658bb585d"
        },
        {
          "tags": [
            "patch"
          ],
          "url": "https://github.com/pgadmin-org/pgadmin4/commit/2ae0d3610"
        }
      ],
      "source": {
        "discovery": "EXTERNAL"
      },
      "title": "pgAdmin 4: SQL injection in COMMENT ON ... IS \u0027\u003cdescription\u003e\u0027 rendering across dialog templates"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007",
    "assignerShortName": "PostgreSQL",
    "cveId": "CVE-2026-12044",
    "datePublished": "2026-06-18T23:37:16.202Z",
    "dateReserved": "2026-06-11T20:40:05.751Z",
    "dateUpdated": "2026-06-22T18:37:05.999Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-12044",
      "date": "2026-06-26",
      "epss": "0.00513",
      "percentile": "0.39784"
    },
    "vulnrichment": {
      "containers": "{\"adp\": [{\"title\": \"CISA ADP Vulnrichment\", \"metrics\": [{\"other\": {\"type\": \"ssvc\", \"content\": {\"id\": \"CVE-2026-12044\", \"role\": \"CISA Coordinator\", \"options\": [{\"Exploitation\": \"none\"}, {\"Automatable\": \"no\"}, {\"Technical Impact\": \"total\"}], \"version\": \"2.0.3\", \"timestamp\": \"2026-06-22T18:36:59.059744Z\"}}}], \"providerMetadata\": {\"orgId\": \"134c704f-9b21-4f2e-91b3-4a467353bcc0\", \"shortName\": \"CISA-ADP\", \"dateUpdated\": \"2026-06-22T18:37:02.398Z\"}}], \"cna\": {\"title\": \"pgAdmin 4: SQL injection in COMMENT ON ... IS \u0027\u003cdescription\u003e\u0027 rendering across dialog templates\", \"source\": {\"discovery\": \"EXTERNAL\"}, \"credits\": [{\"lang\": \"en\", \"type\": \"finder\", \"value\": \"Jasser Chebbi \u003cjasserchebbi@outlook.com\u003e\"}, {\"lang\": \"en\", \"type\": \"remediation developer\", \"value\": \"Dave Page \u003cdpage@pgadmin.org\u003e\"}, {\"lang\": \"en\", \"type\": \"remediation developer\", \"value\": \"Ashesh Vashi \u003cashesh.vashi@enterprisedb.com\u003e\"}], \"metrics\": [{\"format\": \"CVSS\", \"cvssV3_1\": {\"scope\": \"UNCHANGED\", \"version\": \"3.1\", \"baseScore\": 8.8, \"attackVector\": \"NETWORK\", \"baseSeverity\": \"HIGH\", \"vectorString\": \"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H\", \"integrityImpact\": \"HIGH\", \"userInteraction\": \"NONE\", \"attackComplexity\": \"LOW\", \"availabilityImpact\": \"HIGH\", \"privilegesRequired\": \"LOW\", \"confidentialityImpact\": \"HIGH\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"The 8.8 is earned by the stored pgstattuple / pgstatindex sinks (commit 2ae0d3610). The chain: a low-privilege user with CREATE on a schema names a table or index containing an apostrophe (e.g. foo\u0027bar); pgAdmin\u0027s stats templates render that identifier inside a string literal -- pgstattuple(\u0027schema.foo\u0027bar\u0027) -- when a *different* user views statistics on the object. If the viewing user is a PostgreSQL superuser, the SQL injection executes under the superuser role, reaching COPY ... TO/FROM PROGRAM and OS code execution on the DB host. The privilege crossing (low-priv planter -\u003e superuser viewer) is what justifies C:H/I:H/A:H even with S:U: the impact is felt by a different security principal than the attacker, but it lands inside the same DB authority.\\n\\nThe originally-reported Domain Dialog description field is the same code-class but is self-SQLi -- the user injecting the apostrophe is the user whose role runs it. That sub-vector alone would score in the #10026 range (4.3 MEDIUM); it is bundled here because the fix is the same qtLiteral plumbing across all sixteen sites.\\n\\nS:U because pgAdmin does not mediate a privilege boundary between the planter, the viewer, and the DB role; the boundary that is crossed lives entirely inside PostgreSQL\u0027s privilege model.\"}]}, {\"format\": \"CVSS\", \"cvssV4_0\": {\"version\": \"4.0\", \"baseScore\": 8.7, \"baseSeverity\": \"HIGH\", \"vectorString\": \"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\"}, \"scenarios\": [{\"lang\": \"en\", \"value\": \"Same reasoning as the CVSS 3.1 entry: the stored pgstattuple sink is the load-bearing impact (low-priv planter, superuser viewer, superuser-role SQL). VC:H/VI:H/VA:H from the COPY ... TO PROGRAM reach; SC/SI/SA:N because pgAdmin is not the security authority being crossed -- the boundary lives in PostgreSQL.\"}]}], \"affected\": [{\"repo\": \"https://github.com/pgadmin-org/pgadmin4\", \"vendor\": \"pgadmin.org\", \"modules\": [\"Domains\", \"Domain Constraints\", \"Foreign Tables\", \"Languages\", \"Event Triggers\", \"Views\", \"Tables\", \"Indexes\", \"Index Constraints\", \"Exclusion Constraints\", \"Materialized Views\", \"Driver (qtLiteral)\"], \"product\": \"pgAdmin 4\", \"versions\": [{\"status\": \"affected\", \"version\": \"1.0\", \"lessThan\": \"9.16\", \"versionType\": \"custom\"}], \"programFiles\": [\"https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/utils/driver/psycopg3/__init__.py\", \"https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/browser/server_groups/servers/databases/schemas/domains/templates/domains/sql/default/create.sql\", \"https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/browser/server_groups/servers/databases/schemas/tables/templates/tables/sql/16_plus/stats.sql\"], \"defaultStatus\": \"unaffected\"}], \"references\": [{\"url\": \"https://github.com/pgadmin-org/pgadmin4/issues/10078\", \"tags\": [\"issue-tracking\"]}, {\"url\": \"https://github.com/pgadmin-org/pgadmin4/commit/658bb585d\", \"tags\": [\"patch\"]}, {\"url\": \"https://github.com/pgadmin-org/pgadmin4/commit/2ae0d3610\", \"tags\": [\"patch\"]}], \"descriptions\": [{\"lang\": \"en\", \"value\": \"SQL injection in pgAdmin 4 across every dialog template that renders ``COMMENT ON ... IS \u0027\u003cdescription\u003e\u0027`` 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 -- ``\u0027{{ data.description }}\u0027`` -- 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\u0027s 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(\u0027{{schema}}.{{table}}\u0027)`` 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\u0027bar`` and a later stats viewer would render an unbalanced literal.\\n\\nFix is layered:\\n\\n  1. Sites: replace every ``\u0027{{ x.description }}\u0027`` 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 ``\u0027{{ ... }}\u0027`` 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.\"}], \"problemTypes\": [{\"descriptions\": [{\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-89\", \"description\": \"CWE-89 Improper Neutralization of Special Elements used in an SQL Command (\u0027SQL Injection\u0027)\"}, {\"lang\": \"en\", \"type\": \"CWE\", \"cweId\": \"CWE-116\", \"description\": \"CWE-116 Improper Encoding or Escaping of Output\"}]}], \"providerMetadata\": {\"orgId\": \"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007\", \"shortName\": \"PostgreSQL\", \"dateUpdated\": \"2026-06-18T23:37:16.202Z\"}}}",
      "cveMetadata": "{\"cveId\": \"CVE-2026-12044\", \"state\": \"PUBLISHED\", \"dateUpdated\": \"2026-06-22T18:37:05.999Z\", \"dateReserved\": \"2026-06-11T20:40:05.751Z\", \"assignerOrgId\": \"f86ef6dc-4d3a-42ad-8f28-e6d5547a5007\", \"datePublished\": \"2026-06-18T23:37:16.202Z\", \"assignerShortName\": \"PostgreSQL\"}",
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.