Skip to main content
VulnerabilityPublished Updated

CVE-2026-12050: pgAdmin 4 · SQL Injection

Affects pgAdmin 4Source CVE Database V5

0
Compare

Not known to be exploited · CVSS 4.3 Medium : upgrade to 9.16 when convenient.

Data as of 1 Nov 2026, 22:58 UTC

CVSS 3.1 base score
4.3Medium
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.4% chance of exploitation in 30 days – higher than 36% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 9.16
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 18 Jun 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 1 Nov 2026.

What to do

Upgrade pgAdmin 4 to 9.16.

Affected software

ProductAffectedFixed in
pgadmin.orgpgAdmin 4Affected
  • >=1.0 <9.16
Fixed in
  • 9.16
GitHubpgAdmin 4pkg:github/pgAdmin 4Other threatsAffected
  • >=1.0 <9.16
Fixed in
  • 9.16

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

The described fix involves passing user input as bound parameters and schema-qualifying function calls to prevent SQL injection and function hijacking. If you cannot patch yet, restrict access to authenticated users and monitor for unusual activity. Deployments that gate the Query Tool at the application layer should verify that this endpoint is similarly protected.

Description

SQL injection in pgAdmin 4's named restore point endpoint (POST /browser/server/restore_point/{gid}/{sid}). The user-supplied 'value' field was interpolated directly into the SQL string with str.format() instead of being passed as a bound parameter, allowing an authenticated pgAdmin user with a connected PostgreSQL session to inject additional statements through that endpoint. The injected SQL executes under the database role the user is already authenticated as. The defect does not cross a privilege boundary -- the user already has direct SQL access to that role through the Query Tool -- so the attacker gains no capability beyond what their database role already grants them. The marginal impact accounts for the fact that the injection path is not the documented SQL-execution interface, so a deployment that gates the Query Tool at the application layer could see SQL executed through a path it did not anticipate. Fix passes the restore point name as a bound parameter and schema-qualifies the function call as pg_catalog.pg_create_restore_point so a non-default search_path on the connection cannot redirect the call to a shadow definition. A regression test asserts the value arrives as a bound parameter and not spliced into the SQL string. This issue affects pgAdmin 4: from 1.0 before 9.16.

References

Community reviews

Loading reviews…