CVE-2026-12044: SQL Injection in pgAdmin 4 Description Fields

Technical summary

The root cause is improper Jinja template escaping in pgAdmin 4's SQL-generation code. Description fields are interpolated as `'{{ data.description }}'` instead of `{{ data.description|qtLiteral(conn) }}`. A single quote in the description breaks the literal boundary, allowing arbitrary SQL injection. The vulnerability affects 16 sites across Domain, Foreign Table, Language, Event Trigger, and View dialogs, plus 10 additional sinks in pgstattuple/pgstatindex stats templates that embed table/index names without proper identifier escaping. The injected SQL executes under the PostgreSQL role already authenticated in pgAdmin; for roles with COPY TO/FROM PROGRAM, OS command execution on the database host becomes possible. A secondary defect in the qtLiteral utility function silently returned unescaped values when the connection argument was falsy, masking eight additional plumbing bugs elsewhere in the codebase.

Business impact

A database administrator or operator using pgAdmin 4 to manage PostgreSQL instances faces a risk that authenticated users—even those restricted to a read-only or limited-access interface—could execute arbitrary SQL or OS commands by crafting malicious object descriptions. This undermines role-based access controls and audit boundaries. Organizations relying on pgAdmin's Query Tool restrictions to prevent direct SQL access or to enforce least privilege will find those controls circumvented. The impact is elevated if pgAdmin is exposed to less-trusted network segments or if multiple teams share a single instance without strict user isolation.

Affected systems

pgAdmin 4 versions 1.0 through 9.15 (inclusive) are vulnerable. The flaw spans every instance where the affected dialog templates are used, so any pgAdmin deployment managing PostgreSQL databases is at risk if users can create or modify the listed object types (Domains and their constraints, Foreign Tables, Languages, Event Triggers, and Views). Environments where pgAdmin is deployed in a high-trust zone may have lower exposure; conversely, multi-tenant or developer-facing pgAdmin instances have higher risk.

Exploitability

Exploitation requires valid pgAdmin authentication, so external, unauthenticated attacks are not possible. The attack is trivial to execute once authenticated: simply enter a single quote followed by SQL into any description field, save the object, and the injected SQL runs when the definition is rendered. No special tools, unusual network conditions, or complex prerequisite configurations are needed. The barrier to exploitation is extremely low—a user familiar with SQL injection can immediately weaponize this. For users with database-role privileges permitting OS command execution (typically superuser), remote command execution on the PostgreSQL host is achievable.

Remediation

Upgrade pgAdmin 4 to version 9.16 or later, which implements three layers of fixes: (1) replaces all vulnerable `'{{ x }}'` interpolations with the `qtLiteral` filter and plumbs the connection context through affected templates, (2) hardens the `qtLiteral` utility to raise an exception instead of silently returning unescaped values when the connection is absent, surfacing any remaining plumbing gaps, and (3) adds regression and lint tests to detect similar patterns in future code changes. The vendor's advisory should be consulted to confirm the exact patch version and any interim workarounds for instances unable to upgrade immediately.

Patch guidance

Update pgAdmin 4 from your current version to 9.16 or later using the official vendor channels (package manager, Docker image, or direct binary download). Verify the update against the vendor's cryptographic signatures and release notes. Test the patched version in a non-production environment before rolling out to production, paying particular attention to any custom templates or third-party extensions that might interact with the description fields. If you cannot patch immediately, restrict pgAdmin access to highly trusted network segments and audit all user activity creating or modifying Domains, Foreign Tables, Languages, Event Triggers, and Views for anomalous or suspicious descriptions containing SQL keywords or apostrophes.

Detection guidance

Monitor pgAdmin logs for CREATE and ALTER statements targeting Domains, Foreign Tables, Languages, Event Triggers, and Views with description fields containing apostrophes, SQL keywords (SELECT, UNION, DROP, etc.), or semicolons—these are hallmarks of injection attempts. Query the PostgreSQL audit log (if enabled via pgAudit or similar) for unexpected SQL execution stemming from pgAdmin sessions, especially commands that did not originate from interactive Query Tool use or object creation workflows. Alert on any OS-level commands executed by the PostgreSQL process (via auditd, osquery, or similar) that correlate with pgAdmin activity, as this signals potential command-execution abuse. Inspect the pgAdmin event_log table for anomalies in object creation/modification patterns.

Why prioritize this

This vulnerability merits immediate attention despite requiring authentication. First, pgAdmin is a widely-deployed administrative tool with access to critical database infrastructure, so compromise carries high consequence. Second, the exploitation barrier is negligible—any authenticated user can execute this attack in seconds with no special knowledge. Third, the affected version range is broad (1.0–9.15), covering most actively-deployed instances. Fourth, the vulnerability enables privilege escalation from a restricted pgAdmin interface to arbitrary SQL and, potentially, OS command execution. Environments where pgAdmin is exposed to developer or operator communities (vs. a single locked-down admin) face the highest immediate risk.

Risk score, explained

The CVSS 3.1 score of 8.8 (HIGH) reflects a network-accessible service requiring low-complexity exploitation by an authenticated user, with high impact across confidentiality, integrity, and availability. The attack vector is network-based (pgAdmin is typically accessed over HTTP/HTTPS), complexity is low (no special conditions or tools), authentication is required (reducing casual attack surface), and the scope is unchanged (the attacker operates within their existing database-role boundary). The high impact score captures the ability to execute arbitrary SQL and, for privileged roles, OS commands, which can lead to data exfiltration, corruption, or destruction. The lack of active in-the-wild exploitation (KEV status: not listed) does not diminish urgency—this is a straightforward injection flaw affecting infrastructure software, and public disclosure will likely trigger rapid weaponization.

Frequently asked questions