{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-12050", "assignerOrgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007", "state": "PUBLISHED", "assignerShortName": "PostgreSQL", "dateReserved": "2026-06-11T20:40:09.826Z", "datePublished": "2026-06-18T23:37:19.384Z", "dateUpdated": "2026-06-18T23:37:19.384Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "f86ef6dc-4d3a-42ad-8f28-e6d5547a5007", "shortName": "PostgreSQL", "dateUpdated": "2026-06-18T23:37:19.384Z"}, "title": "pgAdmin 4: SQL injection in named restore point endpoint", "affected": [{"vendor": "pgadmin.org", "product": "pgAdmin 4", "repo": "https://github.com/pgadmin-org/pgadmin4", "modules": ["Server Node", "Named Restore Point"], "programFiles": ["https://github.com/pgadmin-org/pgadmin4/blob/master/web/pgadmin/browser/server_groups/servers/__init__.py"], "versions": [{"status": "affected", "version": "1.0", "lessThan": "9.16", "versionType": "custom"}], "defaultStatus": "unaffected"}], "descriptions": [{"lang": "en", "value": "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."}], "references": [{"url": "https://github.com/pgadmin-org/pgadmin4/issues/10026", "tags": ["issue-tracking"]}, {"url": "https://github.com/pgadmin-org/pgadmin4/commit/3379c39865d3ab6f52afce97361fb16bcdd77cd2", "tags": ["patch"]}], "metrics": [{"format": "CVSS", "scenarios": [{"lang": "en", "value": "The attacker is an authenticated pgAdmin user with an established PostgreSQL connection. The injected SQL runs under the PostgreSQL role the user is already authenticated as, so it obtains no read access beyond what their database role already grants them through the supported Query Tool. The marginal integrity impact (I:L) acknowledges that the injection path is not the documented SQL-execution interface, so a deployment that gates the Query Tool at the application layer (for example by hiding the Query Tool UI from certain pgAdmin roles) could see SQL executed it did not anticipate, even though pgAdmin itself does not document or support such gating. Scope is unchanged: pgAdmin does not mediate a privilege boundary between the user and the database; the user supplied those credentials themselves. PoCs that use COPY TO PROGRAM or COPY FROM to read or write files on the PostgreSQL host rely on the connected role already being a PostgreSQL superuser; those operations are available to any superuser through normal SQL execution and are not capabilities granted by this defect.\n\nReviewer note (Dave Page, 2026-06-11): score is sound but mildly generous -- I:L for Query-Tool-gating bypass is charitable since the injection grants the attacker nothing their database role does not already permit through the supported Query Tool. A strict reading would land at I:N (2.7 LOW); 4.3 retained as the conservative-toward-higher choice."}], "cvssV3_1": {"version": "3.1", "attackVector": "NETWORK", "attackComplexity": "LOW", "privilegesRequired": "LOW", "userInteraction": "NONE", "scope": "UNCHANGED", "confidentialityImpact": "NONE", "integrityImpact": "LOW", "availabilityImpact": "NONE", "baseSeverity": "MEDIUM", "baseScore": 4.3, "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N"}}, {"format": "CVSS", "scenarios": [{"lang": "en", "value": "Same reasoning as CVSS 3.1: the attacker already authenticates as the database role they would invoke through the supported Query Tool, so no new vulnerable-system or subsequent-system capability is granted. The marginal VI:L acknowledges the bypass of any application-layer Query Tool gating an operator may have set up, even though pgAdmin does not document or support such gating."}], "cvssV4_0": {"version": "4.0", "vectorString": "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", "baseScore": 5.3, "baseSeverity": "MEDIUM"}}], "problemTypes": [{"descriptions": [{"lang": "en", "description": "CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')", "cweId": "CWE-89", "type": "CWE"}]}], "credits": [{"lang": "en", "value": "Geo <cve@sageby.com>", "type": "finder"}, {"lang": "en", "value": "Dave Page <page@pgadmin.org>", "type": "remediation developer"}, {"lang": "en", "value": "Kundan Sable <kundan.sable@enterprisedb.com>", "type": "remediation reviewer"}], "source": {"discovery": "EXTERNAL"}}}}

{}

{}

{}

{"created": "2026-06-19T01:30:16.172322+00:00", "updated": "2026-06-19T01:30:16.172327+00:00", "vendors": []}