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.
{
"cna_assigner": "PostgreSQL",
"cwe_ids": [
"CWE-89"
],
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/12xxx/CVE-2026-12050.json"
}{
"extracted_events": [
{
"cpe": "cpe:2.3:a:pgadmin:pgadmin_4:*:*:*:*:*:postgresql:*:*",
"range": [
{
"introduced": "1.0"
},
{
"fixed": "9.16"
}
],
"source": "CPE_RANGE"
},
{
"range": [
{
"fixed": "3379c39865d3ab6f52afce97361fb16bcdd77cd2"
}
],
"source": "REFERENCES_COMMIT"
}
]
}