CVE-2026-12050: pgAdmin 4 SQL Injection in Restore Point Endpoint

Technical summary

The vulnerability resides in the POST /browser/server/restore_point/{gid}/{sid} endpoint where the 'value' parameter (restore point name) is interpolated into an SQL string using Python's str.format() method instead of being passed as a bound parameter. This allows SQL injection under the authenticated user's database role. The fix applies parameterized query binding and schema-qualifies the pg_create_restore_point function call to pg_catalog.pg_create_restore_point, preventing search_path manipulation attacks. Regression tests verify that the restore point name travels as a bound parameter rather than as string interpolation.

Business impact

The business risk is moderate. An authenticated pgAdmin user could execute unintended SQL statements against their connected PostgreSQL database without using the documented Query Tool interface. For most deployments, this represents a negligible incremental risk because the attacker already has SQL access to that role through normal Query Tool usage. However, organizations that implement application-layer restrictions on the Query Tool—or that trust pgAdmin's UI to prevent certain operations—could face unexpected SQL execution through this undocumented path. The lack of privilege escalation limits severity, but the bypass of intended controls warrants attention.

Affected systems

All versions of pgAdmin 4 from 1.0 through 9.15 are affected. Version 9.16 and later contain the fix. pgAdmin 4 is the web-based administration and management tool for PostgreSQL databases, widely used in enterprise environments. Any deployment running an affected version with authenticated users and active PostgreSQL connections is at risk.

Exploitability

Exploitation requires an authenticated pgAdmin user account with an active PostgreSQL session—the attacker cannot exploit this remotely without credentials. The endpoint is accessible directly via HTTP POST, and no additional user interaction is required once authenticated. From a practical standpoint, exploitability is straightforward for an insider or compromised account, but the requirement for prior authentication limits the attack surface. The vulnerability is not in CISA's Known Exploited Vulnerabilities catalog, suggesting no active exploitation in the wild at this time.

Remediation

Upgrade pgAdmin 4 to version 9.16 or later as soon as feasible. Organizations unable to upgrade immediately should review access controls to the pgAdmin web interface and restrict authenticated user privileges to the principle of least privilege. If Query Tool restrictions are enforced at the application layer, verify they are effective and document any alternative SQL execution paths. Consider network-level controls to limit pgAdmin access to trusted users and networks.

Patch guidance

Apply the patch by upgrading to pgAdmin 4 version 9.16 or later. Verify the patch is installed by checking the pgAdmin About page or examining version metadata in the deployment. No configuration changes are required post-upgrade. Test the patch in a non-production environment first to confirm restore point functionality and PostgreSQL connectivity remain intact. After patching, verify that restore points can be created and listed as expected.

Detection guidance

Monitor pgAdmin access logs and PostgreSQL audit logs for unusual activity on the /browser/server/restore_point endpoint, particularly POST requests with suspicious characters or SQL syntax in the 'value' parameter (e.g., semicolons, quotes, SQL keywords). Check PostgreSQL logs for unexpected statements executed under authenticated roles. Review pgAdmin's internal audit trail if available. Configure alerting on failed authentication attempts and unusual Query Tool or endpoint access patterns. Network intrusion detection systems can flag HTTP POST requests with SQL injection signatures targeting pgAdmin endpoints.

Why prioritize this

Prioritize patching this vulnerability at a measured pace rather than emergency speed. The CVSS score of 4.3 (Medium) reflects the authentication requirement and lack of privilege escalation. However, organizations that restrict Query Tool access at the application layer should prioritize this more highly, as the vulnerability provides an alternative execution path. Assess your own environment: if pgAdmin users already have unrestricted SQL access, the risk is lower; if Query Tool usage is gated, the risk is higher. No active exploitation has been reported, so this is not an immediate crisis, but it should be included in the next regular patching cycle.

Risk score, explained

The CVSS 3.1 score of 4.3 (Medium severity) reflects: (1) network-accessible attack vector and low attack complexity—anyone who is authenticated can trigger the endpoint without user interaction; (2) authentication requirement (PR:L)—the attacker must already be an authenticated pgAdmin user; (3) limited scope (S:U)—impact is confined to the user's existing role; (4) no confidentiality impact (C:N)—no data is exposed beyond what the role can already see; (5) low integrity impact (I:L)—the attacker can modify data only within their role's permissions; (6) no availability impact (A:N)—the query does not cause denial of service. The 'Low' integrity rating is justified because the injection does not grant new capabilities, only alternative execution paths for existing capabilities.

Frequently asked questions