This vulnerability in pgAdmin 4's POST /browser/server/restore_point/{gid}/{sid} endpoint arises from improper neutralization of special elements in an SQL command (CWE-89). The user-supplied 'value' field was directly interpolated into the SQL string using str.format() instead of being passed as a bound parameter. This allows an authenticated user with an active PostgreSQL session to inject additional SQL statements executed under their existing database role. The impact is limited since the user already has direct SQL access through the Query Tool, so no privilege escalation occurs. The fix involves using bound parameters for the restore point name and schema-qualifying the function call to pg_catalog.pg_create_restore_point, preventing misuse of search_path to redirect the call. A regression test ensures the parameter is properly bound.

An authenticated pgAdmin user with a connected PostgreSQL session can inject SQL commands via the restore point endpoint. The injected SQL executes with the privileges of the user's existing database role, so no privilege escalation or confidentiality breach beyond the user's current permissions occurs. The vulnerability could allow unexpected SQL execution paths if the application layer gates the Query Tool but not this endpoint. There is no impact on confidentiality or availability, only integrity is affected marginally.

Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The vendor fixed the issue by passing the restore point name as a bound parameter and schema-qualifying the function call to prevent redirection. Users should upgrade to pgAdmin 4 version 9.16 or later once available. Until then, restrict access to authenticated users with appropriate database roles and monitor for unusual activity. No additional mitigation is specified by the vendor.