{"id":"CVE-2026-12050","aliases":["EUVD-2026-37964","GHSA-v395-x24j-4r3g","openSUSE-SU-2026:11508-1"],"status":"published","title":"pgAdmin 4: SQL injection in named restore point endpoint","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.\n\nThe 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.\n\nFix 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.\n\nThis issue affects pgAdmin 4: from 1.0 before 9.16.","severity":{"version":"4.0","score":5.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-12","score":0.00426,"percentile":0.37367,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":false},"cwes":["CWE-89"],"published":"2026-06-18T23:37:19Z","modified":"2026-10-28T02:30:23Z","affected":[{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"pgadmin4","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"9.17-1.1"}]}],"bundled":21}],"products":[{"vendor":"pgadmin","product":"pgadmin_4"},{"vendor":"pgadmin.org","product":"pgadmin 4"}],"references":[{"url":"https://github.com/pgadmin-org/pgadmin4/issues/10026","tags":["issue-tracking","Issue Tracking","Patch","report"]},{"url":"https://github.com/pgadmin-org/pgadmin4/commit/3379c39865d3ab6f52afce97361fb16bcdd77cd2","tags":["patch","Patch","fix"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-12050","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-v395-x24j-4r3g"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/12xxx/CVE-2026-12050.json","tags":["advisory"]},{"url":"https://github.com/pgadmin-org/pgadmin4","tags":["package"]},{"url":"","tags":["advisory"]},{"url":"https://www.suse.com/security/cve/CVE-2026-12044","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-12045","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-12046","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-12047","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-12048","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-12049","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-12050","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-1707","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-17347","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-17349","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-17350","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-17351","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-17566","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-7813","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-7814","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-7815","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-7816","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-7817","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-7818","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-7819","tags":["web"]},{"url":"https://www.suse.com/security/cve/CVE-2026-7820","tags":["web"]}],"sources":{"cve":[{"id":"CVE-2026-12050","title":"pgAdmin 4: SQL injection in named restore point endpoint","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.\n\nThe 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.\n\nFix 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.\n\nThis issue affects pgAdmin 4: from 1.0 before 9.16.","status":"published","published":"2026-06-18T23:37:19.384Z","modified":"2026-06-22T19:10:39.879Z","cvss":[{"version":"4.0","score":5.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"medium","assessor":"cna"},{"version":"3.1","score":4.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N","level":"medium","assessor":"cna"}],"cwes":["CWE-89"],"updated_at":"2026-11-02T14:19:47.998488Z"}],"euvd":[{"id":"EUVD-2026-37964","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.\n\nThe 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.\n\nFix 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.\n\nThis issue affects pgAdmin 4: from 1.0 before 9.16.","status":"published","published":"2026-06-18T23:37:19Z","modified":"2026-06-22T19:10:39Z","cvss":[{"version":"4.0","score":5.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"medium"}],"updated_at":"2026-11-02T18:20:33.850201Z"}],"ghsa":[{"id":"GHSA-v395-x24j-4r3g","title":"SQL injection in pgAdmin 4's named restore point endpoint (POST /browser/server/restore_point/...","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.\n\nThe 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.\n\nFix 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.\n\nThis issue affects pgAdmin 4: from 1.0 before 9.16.","status":"published","published":"2026-06-19T00:31:38Z","modified":"2026-06-19T00:31:38Z","cvss":[{"version":"4.0","score":5.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/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","level":"medium"},{"version":"3.1","score":4.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N","level":"medium"}],"cwes":["CWE-89"],"updated_at":"2026-11-02T15:08:54.452189Z"}],"nvd":[{"id":"CVE-2026-12050","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.\n\nThe 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.\n\nFix 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.\n\nThis issue affects pgAdmin 4: from 1.0 before 9.16.","status":"published","published":"2026-06-19T00:16:47.517Z","modified":"2026-10-25T23:10:00.167Z","cvss":[{"version":"4.0","score":5.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/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","level":"medium","assessor":"secondary"},{"version":"3.1","score":4.3,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N","level":"medium","assessor":"secondary"},{"version":"3.1","score":8.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high","assessor":"primary"}],"cwes":["CWE-89"],"updated_at":"2026-11-02T14:12:24.912854Z"}],"osv":[{"id":"CVE-2026-12050","title":"pgAdmin 4: SQL injection in named restore point endpoint","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.\n\nThe 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.\n\nFix 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.\n\nThis issue affects pgAdmin 4: from 1.0 before 9.16.","status":"published","published":"2026-06-18T23:37:19.384Z","modified":"2026-10-28T02:30:23.173595756Z","cvss":[{"version":"4.0","score":5.3,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-89"],"updated_at":"2026-11-02T15:44:57.354194Z"},{"id":"openSUSE-SU-2026:11508-1","title":"pgadmin4-9.17-1.1 on GA media","description":"These are all security issues fixed in the pgadmin4-9.17-1.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2026-08-13T00:00:00Z","modified":"2026-08-14T10:30:29.877481488Z","updated_at":"2026-11-02T16:58:39.516824Z"}]}}