pgAdmin 4 EUVD-2026-51559

Exploitation requires the attacker to hold a low-privileged pgAdmin and PostgreSQL account on the same instance as potential victims, with at least one of the following object-creation privileges granted: CREATE TABLE or CREATE INDEX (to exploit the Index Statistics coll_stats.sql sink, present since pgAdmin 1.0), CREATE PUBLICATION (to exploit the Publications dependencies.sql and get_position.sql sinks, present since pgAdmin 5.0), or CREATE SUBSCRIPTION (to exploit the Subscriptions dependencies.sql and get_position.sql sink, present since pgAdmin 5.0). The attacker must create an object with an apostrophe in its name using PostgreSQL's double-quoted identifier syntax (e.g., CREATE TABLE "foo'bar" (...)). A second condition is that a different pgAdmin user - the injection victim - must navigate to the Statistics tab (for index sinks) or Dependencies tab (for publication/subscription sinks) of the affected object in the pgAdmin browser tree. The victim's database session privileges determine the blast radius of the injected SQL. Deployments where only a single trusted user operates the pgAdmin instance, or where untrusted users are denied all CREATE rights on PostgreSQL objects, are not exploitable. The vulnerability does not affect the single-index stats.sql path already fixed by CVE-2026-12044; only the all-indexes coll_stats.sql listing and the publication/subscription dependency queries are vulnerable in 9.16.

The CVSS 4.0 score of 8.7 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) reflects severe confidentiality, integrity, and availability impact over a network with low complexity. The PR:L metric correctly identifies that exploitation requires a low-privileged account with object creation rights. The UI:N designation warrants scrutiny: a second user must actively navigate to the Statistics or Dependencies tab to trigger the payload, which constitutes a user interaction dependency not reflected in the vector - the real-world trigger is victim routine navigation rather than a fully autonomous attack. Real-world risk is meaningfully elevated for multi-tenant or shared-instance pgAdmin deployments (DBaaS platforms, development team shared tools) where untrusted users coexist with administrators on the same pgAdmin instance. Single-user or single-tenant deployments where only one trusted user operates pgAdmin are not realistically exploitable. The incomplete-fix nature is a material priority signal: organizations that applied pgAdmin 9.16 believing CVE-2026-12044 was fully resolved remain exposed without knowing it. No EPSS score is provided in the input; no KEV listing exists. The combination of no public POC, the PR:L precondition, and the victim-navigation trigger suggests moderate-to-high organizational priority rather than immediate mass exploitation risk - but the cross-user privilege escalation mechanism makes this a meaningful threat in shared environments.

A low-privileged developer with a shared pgAdmin account and CREATE TABLE rights on a team PostgreSQL instance creates a table named using PostgreSQL quoted-identifier syntax that embeds an apostrophe followed by injected SQL - for example, naming the table such that, when its name is interpolated into coll_stats.sql as schemaname = 'public' AND stat.relname = '<name>', the apostrophe breaks out of the string literal. When a database administrator later opens the Index Statistics tab for that schema's indexes in pgAdmin's browser tree, the unescaped {{table}} substitution executes the attacker's injected statement in the DBA's database session with the DBA's credentials. No public exploit code has been identified at time of analysis, but the fix diffs make the vulnerable template patterns and required payload structure immediately apparent to any reviewer.